Method and apparatus for extending the range of the universal serial bus protocol

ABSTRACT

The present invention provides a method and apparatus to be used to extend the range of standard USB devices, and in particular, USB devices operating in accordance with Revision 2.0 of the USB Specification. An extended range hub is provided which comprises a Local Expander (LEX) and a Remote Expander (REX) which can be separated by up to, for example 100 meters. The LEX and REX operate in accordance with an enhanced high-speed USB Extended Range Protocol (USB-ERP) which permits USB devices to be more conveniently located and used, and is in compliance with Revision 2.0 of the USB Specification.

FIELD OF THE INVENTION

[0001] This method and apparatus relates to transmitting signals betweendevices using Universal Serial Bus ports, and in particular, to allowingcommunications between devices using such ports over an extended range.

DESCRIPTION OF THE RELATED ART

[0002] Universal Serial Bus (USB) is a peripheral interface forattaching personal computers to a wide variety of devices, such as, forexample, digital telephone lines, monitors, modems, mice, printers,scanners, game controllers, keyboards, and the like. The creation of USBis a collaborative effort of seven of the largest companies in thecomputer and communication industry: namely Intel, Compaq, Microsoft,NorTel, NEC, Digital and IBM. The specifications defining USB (e.g.Intel et al., Universal Serial Bus Specification, Revision 1.0, January1996; and updated as Revision 1.1 in September 1998, and further updatedas Revision 2.0 in April 2000, and subsequent updates andmodifications—hereinafter collectively referred to as the “USBSpecification”, which term can include future modifications andrevisions) are non-proprietary and are managed by an open industryorganization known as the USB Forum. The USB Specification establishesthe basic criteria that must be met in order to comply with USBstandards. The USB Specification also defines a number of terms andtheir definitions. These terms and definitions are to be used for thepurposes of this specification, unless otherwise stated.

[0003] As an example, it is a requirement of Revision 1.0 of the USBSpecification that a single USB domain shall support up to 127 devicesoperating over a shared medium providing a maximum bandwidth of 12 Mbps.Revision 2.0 increases the maximum bandwidth to 480 Mbps whilemaintaining compatibility with devices manufactured under the criteriaof Revision 1.1;—thus demonstrating ongoing modification of the USBSpecification. Under the USB Specification, a Host Controller thatsupports only a maximum signalling rate of 12 Mbps is referred to as afull-speed host and the transmission of signals from such a hostcontroller is restricted to a full-speed bus. A Host Controller thatsupports a signalling rate of 480 Mbps is referred to as a high-speedhost and said host controller transmits its signals on a high-speed bus.A full-speed Host Controller under the USB Specifications supports twoclasses of devices, namely, low-speed and full-speed devices. Ahigh-speed Host Controller conforming to the USB Specifications supportsthree classes of devices, namely, low-speed, full-speed, and high speeddevices. Low-speed devices have a maximum signalling rate of 1.5 Mbps,full-speed devices have a maximum signalling rate of 12 Mbps, andhigh-speed devices have a maximum signalling rate of 480 Mbps.

[0004] Under the current USB Specifications, including Revision 2.0, thedistance that a device can be separated from its host PC is limited to 5meters. By using a series of USB Hubs—devices that are intended tosupport increased populations rather than increased distances—thisdistance limitation can be increased, in theory, to 30 meters. Usingfive hubs and six 5-meter cables, placed between the hubs, to support asingle device at a range of 30 meters is an expensive and clumsysolution since hubs are currently priced at about $50 US each and atleast two of the five hubs must be provided with electrical power underthis extension method. In addition, using standard 5-meter cablesbetween hubs would mean that some hubs might have to be placed ininsecure and inconvenient locations.

[0005] There is therefore a need for methods and apparatus to allow USBdevices to be positioned at greater distances from the host PC. Forexample, an uninterrupted distance of at least 100 meters is requiredfor compatibility with the standards governing the cabling of commercialbuildings (see, for example, TIA-568-A, Commercial BuildingTelecommunication Cabling Standard, Telecommunications IndustryAssociation, October 1995). Providing for an extended range capabilitywould also create new applications for USB devices as well asfacilitating existing ones. For example, a simple residential or SOHO(small office, home office) surveillance system could be constructed byconnecting consumer quality cameras to a central PC. An overhead mountedmonitor could be monitored from any office in a commercial building.Many other applications are possible.

[0006] Currently, the USB Specifications do not permit the use ofextended ranges.

[0007] It also is a further requirement of the USB Specification thatthe access of each device to the shared communications bus is controlledby a single Host Controller. It is also specified that when a full-speedHost Controller instructs a particular device to place its informationon to the shared bus, the requested information must be received by theHost Controller within 16 full-speed bit-times of said Host Controllerissuing said instruction. Similarly, when a high-speed Host Controllerinstructs a particular device to place its information on to the sharedbus, the requested Information must be received by the Host Controllerwithin 736 high-speed bit-times of said Host Controller issuing saidinstruction. Restriction on the response time ensures that the USBSpecification provides for a high efficiency of bandwidth utilization bylimiting the period during which no information is being transmitted.However, these requirements also limit the physical range of USB devicessince one bit-time at 12 Mbps, which is one full-speed bit-time, isequivalent to the time taken for an electronic signal to traverseapproximately 17 meters of copper cable. One bit-time at 480 Mbps, whichis one high-speed bit-time, is equivalent to the time taken for anelectronic signal to traverse approximately 440 millimeters of cable.

[0008] Further, although the USB device must respond to a request fromthe full-speed Host Controller within 16 full-speed bit-times, 7.5full-speed bit-times is allocated for delay within a full or low-speedUSB device and its associated 5 meter cable. This allocation retainsonly 8.5 full-speed bit-times at 12 Mbps for additional cable delay. Thetime represented by 8.5 full-speed bit-times is equivalent to the delayincurred by electronic signals in traversing approximately 144 meters ofcable. The distance travelled within the allowed time span forfull-speed is insufficient to satisfy the round trip cable length of 200meters required by the premise cabling specification.

[0009] For the high-speed Host Controller, a device must respond to theHost Controller within 736 high-speed bit-times and 217 high-speedbit-times of the restricted response time of 736 high-speed bit-times isallocated for delay within a high-speed USB device and its 5 metercable. This allocation, thus, retains 519 full-speed bit-times at 480Mbps for additional cable delay. The time represented by 519 high-speedbit-times represents a distance of 227 meters of cable. However,according to the USB Specifications, a high-speed host must also supportfull and low-speed devices which operate under the full-speed bus. Thetime allocated for delay within a full or low-speed USB device and itsassociated 5 meter cable is 7.5 full-speed bit-times which is equivalentto 300 high-speed bit-times. Therefore, in the case where data istransferred between a high-speed host and a full or low-speed USBdevice, only 436 bit-times is retained for additional cable delay. Thetime represented by 436 bit-times at 480 Mbps is equivalent to a cabledistance of 190 meters. In order to maintain compatibility with full andlow-speed devices, the maximum cable length for high speed is thenrestricted to 190 meters which does not meet the specified round tripcable length of 200 meters.

[0010] It is a further feature of the USB Specification that the USBSpecification (or protocol) partitions access to the shared bus intodiscrete units known as “frames”, for a full-speed host, and“microframes”, for a high-speed host. The duration of a frame is 1 mswhile that of a microframe is 125 _(μ)s. Eight microframes areequivalent to one frame.

[0011] Further, the USB Specification also requires that at least fourseparate types of data streams or “traffic” are recognized, namelyisochronous transfers, control transfers, interrupt transfers, and bulktransfers.

[0012] Isochronous data transfer is characterized as being a datatransfer wherein data flows essentially continuously, and at a steadyrate, in close timing with the ability of the receiving mechanism toreceive and use the incoming data. Thus, isochronous transfers areconsidered to be “time-relevant”.

[0013] This type of data transfer is distinguished from asynchronousdata transfer, which pertains to processes that proceed independently ofeach other until a dependent process has to “interrupt” the otherprocess, and synchronous data transfer, which pertains to processes inwhich one process has to wait on the completion of an event in anotherprocess before continuing. These data transfer methods are said to benon-time-relevant. Instead, a correct response to any request isrequired.

[0014] In our co-pending PCT patent application No. PCT/CA00/00157(published as WO00/49507 on Aug. 24, 2000), herein incorporated byreference, a system for extending the range of the USB protocol isdescribed which allows for cable distances of over 100 meters to beachieved for connecting USB devices.

[0015] For the purposes of the present invention, this previous methodwill hereinafter be referred to, in general, as the “USB Extended RangeProtocol”. This USB Extended Range Protocol (USB-ERP) provides a methodfor extending the distance between USB devices to distances over 100 m,and which is in compliance with all sections of Revision 1.0 of the USBSpecifications, and any earlier versions, with the exception ofdistances between devices.

[0016] Using this method, in one feature, the data stream was anisochronous data stream, and in more general terms, was a time relevantdata stream, wherein the first or the subsequent original, outgoingdigital signal was a request for time-relevant data, and preferably, foran isochronous data stream.

[0017] Also, it was stated that the digital signal is stored. Thisstorage period, and any other storage period referred to in the presentspecification, may be a very short time period. For example, in the casewhere the reply signal is received in time to respond to the originaldigital, the reply signal may be immediately forwarded with minimalstorage time.

[0018] Further, it was stated that the digital signals might beconverted to signals which are more suitable for transmission, and thetransmission signals can be converted back to digital signals, on boththe outgoing and incoming signals. This optional conversion step is onlynecessary if the digital signals are converted, for some reason, fortransmission purposes. Otherwise, the digital signals can be sent intheir original form. For the purposes of the present specification, itshould be understood, however, that the digital signals may be convertedfor transmission purposes, but they will preferably be converted back tothe same, or a similar digital signal, when required.

[0019] Devices operating using the USB-ERP have met with commercialsuccess. However, while the methods and devices described according tothe USB-ERP have been useful, modifications to the USB Specificationhave made enhancement of the USB-ERP desirable. Thus, the improved ormodified features of the current USB Specifications, namely USB 2.0,require some enhancement of the previously described system in order toachieve optimum performance. In view of these modifications, the systempreviously described in PCT application No. PCT/CA00/00157, whileproviding acceptable performance, could benefit from providingadditional enhancements to improve performance when high-speed devicesare being used.

[0020] For example, in the current USB Specifications, the hostcontroller may inquire about the availability of space at a high-speeddevice endpoint using a PING special token. This mechanism allows thehost to wait until there is enough space at the device endpoint beforetransmitting subsequent data packets. The PING protocol reduces theamount of wasted bandwidth that is associated with downstream transfersof control and bulk data when the endpoint is not capable of acceptingdata. The PING protocol is only valid for bulk and control datatransfers between a high-speed host and a high-speed device wherein dataflows from the host to the device. PING special tokens are transmittedin the same manner as a normal token packet. Also, the current revisionof the USB Specification requires compatibility between hosts anddevices which were manufactured in accordance with the different USBSpecification Revisions. For example, a high speed host must still beable to operate when using a full speed or low speed device.

[0021] Thus, it would still be desirable to provide further improvementsto the technology by providing a method and apparatus for enabling datatransmission equipment, and in particular, time relevant ornon-time-relevant data transmission equipment utilizing the USBSpecification, to be used over an extended range. Accordingly, thecurrent invention therefore again uses the fundamental characteristicsof isochronous and asynchronous data transfer, and more generally anytime relevant or non-time-relevant data transmission, and the existenceof regular protocol frames and microframes in order to provide methodsand apparatus to enable data transmission over extended distances.

[0022] It is, therefore, an object of the present invention to providemethods and apparatus to enable devices, hubs and controllers and otherdevices that conform to the USB Specification to communicate overdistances greater than that currently permitted under said USBSpecification.

[0023] It is a further object of the present invention that the extendedrange be achieved without the need for intermediate hubs, repeaters orother methods of electronic signal regeneration.

[0024] It is a further object of the present invention that no hardwareor software changes need to be made to the existing devices, hubs, andcontrollers supported by the system, and in particular, to either theisochronous or asynchronous systems operating under the USBSpecification. The invention, thereby, may be incorporated into networkscomposed of both conventional range and extended range devices.

[0025] It is a further object of the present invention that theapparatus be very cost effective, consistent with the broadestpopulation of devices targeted by the USB industry.

[0026] These and other objects of the invention, which will becomeapparent herein, are fully, or at least partially attained by thepresent invention as described hereinbelow.

SUMMARY OF THE INVENTION

[0027] Enhancement of the USB-ERP, previously disclosed is thereforedesired. Accordingly, the present invention provides an enhancedhigh-speed method for transmitting a data stream between a hostcontroller and a peripheral device over an extended distance inaccordance with the USB Extended Range Protocol (hereinafter the“USB-ERP”), wherein said method additionally comprises modifications toallow for compliance with Revision 2.0 of the USB Specifications.Preferably, these enhancements include, in general: providing rangeextension between high speed devices, while maintaining compatibilitybetween High-Speed devices and Full Speed or Low Speed devices;providing improved ability to handle interrupt, control, bulk andisochronous transfers according to Revision 2.0; and/or providing theability to handle PING protocols.

[0028] Accordingly, the present invention provides an enhancedhigh-speed method of transmitting a data stream, with modifications toallow for compliance with Revision 2.0 of the USB Specification, whereinsaid enhanced high-speed USB-ERP comprises:

[0029] a. feeding a first original, outgoing digital signal from a hostcontroller to a local expander unit;

[0030] b. optionally converting said outgoing digital signal into aconverted outgoing signal having a format suitable for transmission overextended distances;

[0031] c. transmitting either said outgoing digital signal or saidconverted outgoing signal, as an outgoing transmission signal, over asignal distribution system;

[0032] d. receiving said outgoing transmission signal at a remoteexpander unit,

[0033] e. optionally converting said outgoing transmission signal tosaid first original outgoing digital signal;

[0034] f. delivering said first original outgoing digital signal fromsaid remote expander to at least one peripheral device;

[0035]9. receiving, at said remote expander, a reply digital signal fromsaid peripheral device;

[0036] h. optionally converting said reply digital signal Into aconverted reply signal having a format suitable for transmission overextended distances,

[0037] i. transmitting said reply digital signal or said converted replysignal as a reply transmission signal over said signal distributionsystem;

[0038] j. receiving said reply transmission signal at said localexpander;

[0039] k. optionally converting said reply transmission signal to saidoriginal reply digital signal;

[0040] l. storing said reply digital signal as a stored reply digitalsignal until the receipt of a subsequent original, outgoing digitalsignal from said host controller, which subsequent signal is the sameas, or similar to, said first original outgoing digital signal; and

[0041] m. forwarding said stored reply digital signal to said hostcontroller in response to said subsequent original outgoing digitalsignal.

[0042] The phrase “enhanced high-speed” is preferably to be used tostate that the USB-ERP operates in accordance with Revision 2.0 of theUSB Specification (other than for separation distances between devices).This method can, therefore, allow for the speed advantages of high speedhost controllers and/or high speed devices to be utilized.

[0043] With respect to isochronous transfers, or more generally, timerelevant data streams, the enhanced high-speed USB-ERP method of thepresent invention allows for the transfer of isochronous data from bothhosts and devices at the higher transfer rates allowed under Revision2.0, and thus permits the high transfer rates of high speed devices andhost controllers to be utilized.

[0044] Thus, the present invention also provides an enhanced high-speedmethod as described hereinabove, which method provides for thetransmission of isochronous data according to Revision 2.0 of the USBSpecification wherein isochronous data is transmitted from a peripheraldevice and is received by a host controller, said method comprising:

[0045] a. transmitting a request for isochronous data from a hostcontroller to a local expander,

[0046] b. forwarding said request for isochronous data from said localexpander to a remote expander over a signal distribution system;

[0047] c. delivering said forwarded request for isochronous data to atleast one peripheral device;

[0048] d. transmitting the requested isochronous data from saidperipheral device to said remote expander,

[0049] e. forwarding said requested Isochronous data from said remoteexpander to said local expander over said signal distribution system;

[0050] f. storing said requested isochronous data in a packet buffer atsaid local expander;

[0051] g. transmitting a subsequent request for isochronous data fromsaid host controller to aid local expander;

[0052] h. receiving said subsequent request for isochronous data at saidlocal expander; and

[0053] I. retrieving the stored isochronous data from said localexpander;

[0054] II. delivering said stored isochronous data to said hostcontroller;

[0055] III. forwarding said subsequent request for isochronous data fromsaid local expander to aid remote expander over said signal distributionsystem; and

[0056] IV. repeating steps (c) through (h) for said subsequent requestand any further subsequent requests for isochronous data.

[0057] Additionally, the method of the present invention also provide amethod as described hereinabove, wherein said method provides a methodfor transmission of isochronous data according to the USB Specificationwherein isochronous data is transmitted from a host controller and isreceived by a peripheral device, said method comprising:

[0058] a) receiving, at a local expander, an original notification ofisochronous a host controller;

[0059] b) forwarding said original notification of isochronous data fromsaid local expander to a remote expander over signal distributionsystem;

[0060] c) receiving, at a remote expander, said forwarded originalnotification of isochronous data;

[0061] d) delivering said forwarded notification of asynchronous data toat least one peripheral device;

[0062] e) receiving, at a local expander, an original isochronous datapacket from a host controller;

[0063] f) forwarding said original isochronous data packet from saidlocal expander to a remote expander over a signal distribution system;

[0064] g) receiving, at a remote expander, said forwarded originalisochronous data packet; and

[0065] h) delivering said forwarded original isochronous data packet toat least one peripheral device.

[0066] Yet still further, the present invention also provides a methodas described hereinabove wherein additionally comprising the followingsteps after step (b), namely:

[0067] i. Determining whether said local expander already possesses saidrequested isochronous data;

[0068] ii. Generating a synthetic data packet if no such requestedisochronous data is present; and

[0069] iii. Delivering said synthetic isochronous data to said hostcontroller.

[0070] Also, the method of the present invention provides a method asdescribed hereinabove additionally comprising the following steps afterstep (b), uniquely for data transfers conforming to the USBSpecifications wherein data is transmitted from a high-speed host and isreceived by a full-speed device, namely:

[0071] i) Determining whether said local expander already possesses saidrequested isochronous data;

[0072] ii) Generating a synthetic not-yet packet if no such requestedisochronous data is present; and

[0073] iii) Delivering said not-yet packet to said host controller.

[0074] With respect to non-time-relevant data streams, and inparticular, asynchronous data streams, the present invention provides anenhanced high-speed method for transmission of asynchronous dataaccording to the USB Specification wherein asynchronous data istransmitted from a peripheral device and is received by a hostcontroller, said method comprising:

[0075] a) receiving, at a local expander, an original request forasynchronous data from a host controller;

[0076] b) forwarding said original request for asynchronous data fromsaid local expander to a remote expander over a signal distributionsystem;

[0077] c) receiving, at a remote expander, said forwarded originalrequest for asynchronous data;

[0078] d) delivering said forwarded original request for asynchronousdata from said peripheral device;

[0079] e) receiving; at said remote expander, the requestedasynchronous, data from said peripheral device;

[0080] f) forwarding said requested asynchronous data from said remoteexpander to said local expander over said signal distribution system;

[0081] g) storing, in a packet buffer at said local expander, saidrequested asynchronous data;

[0082] h) receiving, at said local expander, a subsequent request forasynchronous data from said host controller; and

[0083] i) retrieving the stored asynchronous data from said packetbuffer;

[0084] ii) delivering said retrieved asynchronous data to said hostcontroller;

[0085] i) receiving, at said local expander, an outgoing acknowledgmentsignal from said host controller,

[0086] j) absorbing, at said local expander, said outgoingacknowledgement signal.

[0087] Further, the present invention also provides a method asdescribed hereinabove additionally comprising the following steps afterstep (b), namely:

[0088] i) Determining whether said local expander already possesses saidrequested asynchronous data;

[0089] ii) Generating a negative acknowledgement packet if no suchrequested asynchronous data is present; and

[0090] iii) Delivering said negative acknowledgement packet to said hostcontroller.

[0091] Still further, the present invention provides a method asdescribed hereinabove additionally comprising the following steps afterstep (b), generally for high bandwidth data transfers conforming to theUSB Specifications wherein data is transmitted from a high-speed hostand is received by a high-speed device, namely:

[0092] a. Determining whether said local expander already possesses saidrequested asynchronous data;

[0093] b. Generating a synthetic data packet if no such requestedasynchronous data is present; and

[0094] c. Delivering said synthetic asynchronous data to said hostcontroller.

[0095] When data is transmitted from a high-speed host, and is receivedby a low-speed or full-speed device, the method of the present inventionalso provides the following steps after step (b), uniquely for datatransfers conforming to the USB Specifications wherein data istransmitted from a high-speed host and is received by a low-speed orfull-speed device, namely:

[0096] a. Determining whether said local expander already possesses saidrequested asynchronous data;

[0097] b. Generating a synthetic not-yet packet if no such requestedasynchronous data is present; and

[0098] c. Delivering said synthetic not-yet packet to said hostcontroller.

[0099] Further, the method can also comprise the following steps afterstep (e), namely:

[0100] i) generating an acknowledgement packet at said remote expander;and

[0101] ii) delivering said acknowledgement packet to said peripheraldevice.

[0102] Interrupt transfers, control transfers, and bulk transfers areall categorized by the USB Specifications as types of asynchronous datatransfer, and are all non-time-relevant data streams However, the maincharacteristic that distinguishes interrupt transfers from controltransfers and bulk transfers is periodicity. For example, in accordancewith the USB Specification, Revision 2.0, interrupt transfers haveguaranteed bandwidth on the shared bus and therefore can occur atregular time intervals. However, control transfers and bulk transferscan occur any time and can take place when the shared bus has unoccupiedbandwidth. Control transfers have very little guaranteed bandwidth onthe shared bus. Bulk transfers have no guaranteed bandwidth. Therefore,bulk transfers have the lowest priority on the shared bus and only takeplace when there is available bandwidth after the bandwidth required byall the other transfers has been accounted for.

[0103] Control transfers are characterized by having three transferphases for transmitting each set of inbound or outbound data and saidtransfer phases are: the set-up phase, the data phase, and the statusphase.

[0104] With respect to control and bulk transfers, which are treated astwo special cases of asynchronous transfers wherein data requests fromthe host controller are generated non-periodically or on an as-neededbasis, the invention provides a enhanced high-speed USB-ERP additionallycomprising the following step after determining whether the localexpander already possesses said requested asynchronous data, namely:

[0105] a. Absorbing at said local expander said subsequent request forasynchronous data.

[0106] For the purposes of the present invention, the term “absorbing”is used to describe a process wherein the software recognizes that theinformation stored is not essential, or is no longer essential, andtherefore simply removes the information from storage without passing iton to any further devices.

[0107] For interrupt transfers, which are a special case of asynchronoustransfers wherein data requests from the host controller are generatedperiodically, the present invention also provides a method according toan enhanced high-speed USB-ERP additionally comprising the followingsteps after step (h) above, uniquely for interrupt data transferswherein asynchronous data is transmitted from a peripheral device and isreceived by a host controller, namely,

[0108] a. Forwarding said subsequent request for asynchronous data fromsaid local expander to a remote expander over a signal distributionsystem;

[0109] b. Delivering said forwarded subsequent request for asynchronousdata from said remote expander to said peripheral device; and

[0110] c. Receiving, at said remote expander, the requested asynchronousdata from said peripheral device.

[0111] In a preferred embodiment, the present invention also provides amethod as described hereinabove with respect to the present invention,which provides an enhanced high-speed USB-ERP method for transmission ofasynchronous data according to the USB Specification, whereinasynchronous data is transmitted from a host controller and is receivedby a peripheral device, said method comprising:

[0112] a) receiving, at a local expander, an original notification ofasynchronous data from a host-controller,

[0113] b) forwarding said original notification of asynchronous datafrom said local expander to a remote expander over a signal distributionsystem;

[0114] c) receiving, at a remote expander, said forwarded originalnotification of asynchronous data;

[0115] d) delivering said forwarded notification of asynchronous data toat least one peripheral device;

[0116] e) receiving, at a local expander, an original asynchronous datapacket from a host controller;

[0117] f) forwarding said original asynchronous data packet from saidlocal expander to a remote expander over a signal distribution system;

[0118] g) receiving, at a remote expander, said forwarded originalasynchronous data packet,

[0119] h) delivering said forwarded original asynchronous data packet toat least one peripheral device;

[0120] i) receiving, at said remote expander, an inbound acknowledgmentpacket from said peripheral device;

[0121] l) forwarding said inbound acknowledgment packet from said remoteexpander to said local expander over said signal distribution system;

[0122] k) storing, in a packet buffer at said local expander, saidinbound acknowledgment packet;

[0123] l) receiving, at said local expander, a subsequent notificationof asynchronous data from said host controller;

[0124] m) receiving, at said local expander, a subsequent asynchronousdata packet from said host controller; and

[0125] i) retrieving said stored inbound acknowledgment packet from saidpacket buffer; and

[0126] ii) delivering said retrieved inbound acknowledgment packet tosaid host controller.

[0127] In a further preferred embodiment, the method describedhereinabove additionally comprises the following steps, namely:

[0128] i) Determining whether said local expander already possesses saidinbound acknowledgment packet;

[0129] ii) Generating a negative acknowledgment packet if no suchinbound acknowledgment packet is present; and

[0130] iii) Delivering said negative acknowledgment packet to said hostcontroller.

[0131] For interrupt transfers, the invention provides the followingsteps after steps l) and m) described hereinabove, namely:

[0132] a. Forwarding said subsequent notification of asynchronous dataand asynchronous data packet from said local expander to a remoteexpander over a signal distribution system;

[0133] b. Delivering said forwarded subsequent notification ofasynchronous data and asynchronous data packet to said peripheraldevice;

[0134] c. Receiving, at said remote expander, the inboundacknowledgement packet from said peripheral device;

[0135] d. Repeating steps (j) through (m) for said subsequentnotification and data packet and any further subsequent notifications ofasynchronous data and asynchronous data packets.

[0136] For control and bulk transfers, the invention provides thefollowing steps after steps l) and m) described hereinabove, namely:

[0137] a. Absorbing at said local expander said subsequent notificationof asynchronous data and said subsequent asynchronous data packet.

[0138] With respect to both time-relevant and non-time relevant datastreams, a guard time can be imposed after a data packet is transmittedfrom a remote expander to a USB device, which guard time is set to avalue that is dependent upon the transfer type of said transmitted datapacket, said method comprising:

[0139] (a) Receiving, at a remote expander, an outbound data packet,

[0140] (b) Determining, at a remote expander, the transfer type of saidoutbound data packet,

[0141] (c) Forwarding said outbound data packet from said remoteexpander to a USB device,

[0142] (d) Setting the value of a transmission guard timer to a valuethat is dependent upon said determined transfer type; and

[0143] (e) Inhibiting further outbound transmissions until said guardtimer has expired.

[0144] In an additional feature, the present invention also provides amethod as described hereinabove with respect to the present invention,wherein said method provides an enhanced high-speed USB-ERP method forhandling the PING flow control protocol, which is used uniquely forcontrol and bulk data transfers wherein asynchronous data is transmittedfrom a high-speed host to a high-speed device, said method comprising:

[0145] a) receiving, at a local expander, a PING flow control probe froma host controller;

[0146] b) forwarding said flow control probe from said local expander toa remote expander over a signal distribution system;

[0147] c) receiving, at a remote expander, said forwarded flow controlprobe;

[0148] d) delivering said forwarded flow control probe to at least onehigh-speed peripheral device;

[0149] e) receiving, at remote expander, the requested reply from saidperipheral device;

[0150] f) receiving, at local expander, said requested reply;

[0151] g) storing, in a packet buffer at said local expander, saidrequested reply;

[0152] h) receiving, at said local expander, a subsequent PING flowcontrol probe from said host controller; and

[0153] i) retrieving said stored reply from said packet buffer;

[0154] ii) delivering said retrieved reply to host controller,

[0155] i) absorbing, at said local expander, said subsequent flowcontrol probe.

[0156] In a preferred feature, the method also provides the followingadditional steps after step (b) described hereinabove, namely:

[0157] i) Determining whether said local expander already possesses saidrequested reply;

[0158] ii) Generating a negative acknowledgement packet if no suchrequested reply is present;

[0159] iii) Delivering said negative acknowledgement packet to said hostcontroller.

[0160] Additionally, the present invention provides apparatus which arecapable of providing the processing logic described hereinabove.

DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0161] Although a number of signal distribution systems may be used, asdescribed hereinabove, preferably the signals are transmitted over asignal distribution system that utilizes fibre optic cabling. Using thismethod of device connection provides a low cost and effective means fordata transmission. However, in another embodiment of the system, signalscan be transmitted over coaxial cable, Unshielded Twisted Pair (UTP)cable or wire, shielded cable, or wireless transmission methods.

[0162] While the methods and apparatus of the present invention havegeneral utility in a variety of applications, it is of primaryimportance that the data transmission methods and apparatus of thepresent invention allow for compliance with the USB Specification (withthe exception of the distance requirements). In one embodiment, theoriginal signal from the host controller is a request for data from aperipheral device. The peripheral devices can include devices selectedfrom cameras, keyboards, mice, monitors, speakers, and the like.

[0163] For time relevant (isochronous) data streams, and in particular,during operations utilizing the methods and apparatus of the presentinvention in applications involving extended range transmissions, it ispreferred that the apparatus be capable of recognizing isochronoustransfers, when they are received. The data contained within theisochronous transfer is then stored within the system for a period oftime.

[0164] Preferably, the data that is received during a particular timeperiod may be stored and then transmitted in a following time period.Additionally, a further preferred embodiment of the present invention isthat isochronous transfers originating from a plurality of sources maybe stored, and retransmitted.

[0165] In the operation of a preferred embodiment of the currentinvention, a host controller (which preferably is a PC) may issue arequest to a device for the transfer of isochronous data. The request isreceived by the apparatus of the present invention, and retransmitted tothe target device. When the requested isochronous transfer response isreceived by the apparatus from the target device, the isochronous datais stored within the internal memory of the apparatus. During asubsequent time period, the host controller will again issue a requestto the target device for the transfer of isochronous data. The apparatuswill again retransmit this request to the target device. In addition,however, the apparatus recognizes that it currently has isochronous datafrom the target device stored in its internal memory. The apparatussends this data to the host controller within the 16 full-speed bit-timemargin in the case of a full-speed bus (or within the 736 high-speedbit-time margin in the case of a high-speed bus) relevant to the currentrequest within the time period. In this manner, the apparatus uses datacollected in a previous time period to satisfy the response timerequirement of a current time period.

[0166] For time relevant data streams, the term “time period” preferablyrefers to a single “frame” (1 ms) in the case of a full-speed bus or“microframe” (125 _(μ)s) in the case of a high-speed bus, as defined inthe USB Specification.

[0167] When a packet is received from the target device, and no furtherrequest for data is received from the host controller, the last datapacket or packets received and stored (hereinafter the “vestigial”packets) are preferably removed from the system so that they are nottransmitted when and if a further request is received from the hostcontroller. Preferably, this is achieved by modification of the methoddescribed hereinabove by additionally comprising the following stages,namely:

[0168] i) Detecting when a new time period has begun;

[0169] ii) Examining the properties of each packet buffer;

[0170] iii) Determining whether the data packet contained in saidexamined packet buffer has been stored for at least the duration of onecomplete time period;

[0171] iv) Discarding said contained data packet if said contained datapacket has been stored for the duration of at least one complete timeperiod; and

[0172] v) Repeating steps i) through iv) for each packet buffer in thesystem.

[0173] In an alternative embodiment of the invention, the apparatushandles the first request for the inbound transfer of isochronous datain a unique manner. This unique manner requires the apparatus togenerate its own synthetic inbound data packet.

[0174] It is possible that packets sent from the Remote Expander may notarrive at the Local Expander In the order expected by the LocalExpander. In order to avoid difficulties that might be caused by thisoccurrence, the method of the present invention also preferablycomprises the following stages, namely:

[0175] 1) Storing the address of the requested peripheral device at saidremote expander after the local expander has delivered the forwardedrequest for isochronous data; and further comprising the following stepsafter transmitting the requested isochronous data from the peripheraldevice to the remote expander, namely:

[0176] a) Retrieving the address of said requested peripheral device atsaid remote expander unit; and

[0177] b) Adding said retrieved address to said requested isochronousdata.

[0178] With respect to non-time relevant data streams, and inparticular, asynchronous data signals, streams or transfers, it ispreferred, during practice of the method, or during use of the apparatusof the present invention, that the system be preferably capable ofrecognizing asynchronous transfers, when they are received. The datacontained within the asynchronous transfer is then stored within thesystem for a period of time. Accordingly, the data that is receivedduring a particular time period may be stored and then transmitted in afollowing time period. Additionally, a further preferred embodiment ofthe present invention is that asynchronous transfers originating from aplurality of sources may be stored, and retransmitted.

[0179] In the operation of a preferred embodiment of the currentinvention with respect to a non-time relevant data stream, and anasynchronous data stream in particular, a host controller may issue arequest to a device for the transfer of asynchronous data. The hostcontroller must receive a response to corresponding to the issuedrequest within 16 full-speed bit-times in the case of a full-speed bus(or 736 high-speed bit-times in the case of a high-speed bus) accordingto the USB Specification. The request is received by the apparatus ofthe present invention, and retransmitted to the target device. Onreceipt of an initial request, the apparatus generates and transmits asynthetic data packet to the host in order to satisfy the response timerestriction. When the requested asynchronous transfer response isreceived by the apparatus from the target device, the asynchronous datais stored within the internal memory of the apparatus. In the case wheredata flows from the device to the host, the apparatus generates andtransmits a synthetic acknowledgment to the device on receipt of theresponse from the device. During a subsequent time period, the hostcontroller will again issue a request to the target device for thetransfer of asynchronous data. In addition, however, the apparatusrecognizes that it currently has asynchronous data from the targetdevice stored in its internal memory. The apparatus sends this data tothe host controller within the amount of time specified by the USBSpecification relevant to the current request within the current timeperiod. In the case where data flows from the device to the host, thehost generates an acknowledgment on receipt of the requested data andthe acknowledgment is absorbed by the apparatus. In this manner, theapparatus uses data collected in a previous time period to satisfy theresponse time requirement of a current time period.

[0180] For interrupt data streams or transfers, a special case ofasynchronous data streams or transfers, the term “time period”preferably refers to a single “frame” (1 ms) in the case of a full-speedbus or “microframe” (125 _(μ)s) in the case of a high-speed bus, asdefined in the USB Specification. However, the term “time period” mayalso apply to a portion of a frame or microframe, or a plurality offrames or microframes.

[0181] Furthermore, for interrupt data streams or transfers, subsequentrequests for the transfer of data generated by the host areretransmitted to the device by the apparatus.

[0182] For bulk or control data streams or transfers, two special casesof asynchronous data streams or transfers, the term “time period” canrefer to a portion of a frame or microframe, a single frame ormicroframe, a plurality of frames or microframes, or the like. Saidframe and microframe are as defined in the USB Specification.

[0183] Furthermore, for bulk or control data streams or transfers,subsequent requests for the transfer of data generated by the host areabsorbed by the apparatus.

[0184] In the operation of a preferred embodiment of the currentinvention, a high-speed host controller may issue a PING control flowprobe to a high-speed device, with control or bulk endpoints, inquiringabout the availability of space within the device for asynchronous data.The control flow probe is received by the apparatus of the presentinvention, and retransmitted to the target device. When the requestedresponse is received by the apparatus from the target device, theresponse is stored within the internal memory of the apparatus. During asubsequent time period, the host controller will again issue a PING tothe target device inquiring about the availability of space forasynchronous data. The apparatus will again retransmit this flow controlprobe to the target device. In addition, however, the apparatusrecognizes that it currently has a response from the target devicestored in its internal memory. The apparatus sends this response to thehost controller within the 736 high-speed bit-time margin relevant tothe current request within the time period. In this manner, theapparatus uses data collected in a previous time period to satisfy theresponse time requirement of a current time period.

[0185] In a preferred embodiment of either a time relevant or non-timerelevant data transmission, the extended distance exceeds 5 meters, morepreferably, exceeds 30 meters, and still more preferably, equals orexceeds 100 meters. In particular, the distance between the localexpander and the remote expander exceeds 5 meters, more preferably,exceeds 30 meters, and still more preferably, equals or exceeds 100meters.

[0186] As with the prior art, the method of the present invention can beused in a system wherein said host controller is a PC, and saidperipheral device is, for example, a camera, a mouse, a keyboard, amonitor or a speaker or speakers. The “host controller” is preferably aPC, as has been previously stated. However, the host controller may alsobe part of a computer system, and in particular, part of a networkedcomputer system.

[0187] By utilizing the method and apparatus of the present invention,it is possible to have transfer of time relevant data or non-timerelevant data, and isochronous data or asynchronous data in particular,over extended distances, and in particular over distances greater thanspecified in the USB Specification.

[0188] However, other features of the present invention, as well asother objects and advantages attendant thereto, are set forth in thefollowing description and the accompanying drawings in which likereference numerals depict like elements.

BRIEF DESCRIPTION OF THE DRAWINGS

[0189] The invention, and various aspects thereof, will be described byreference to the attached drawings wherein:

[0190]FIG. 1 is a visual representation of a PC equipped with ExtendedRange Hub and USB Devices;

[0191]FIG. 2 is a schematic drawing of an embodiment of the inventiondesigned to operate using fibre optic cabling as a signal distributionsystem;

[0192]FIG. 3 is a timing diagram showing isochronous transfers accordingto the USB protocol;

[0193]FIG. 4 is a timing diagram showing isochronous transfers accordingto the current invention;

[0194]FIG. 5 is a schematic drawing of one embodiment of a LocalExpander according to the invention;

[0195]FIG. 6 is a schematic drawing of one embodiment of a REX-FPGAaccording to the invention;

[0196]FIG. 7 is a sequence diagram showing an isochronous input transferbetween a full-speed host and a full-speed device according to theinvention;

[0197]FIG. 8 is a sequence diagram showing an isochronous outputtransfer between a full-speed host and a full-speed device according tothe invention;

[0198]FIG. 9 is an algorithm for implementing isochronous inputtransfers between a full-speed host and a full-speed device, at theLocal Expander and Remote Expander, according to the invention;

[0199]FIG. 10 is an algorithm for implementing isochronous outputtransfers between a full-speed host and a full-speed device, at theLocal Expander and Remote Expander, according to the invention;

[0200]FIG. 11 is a sequence diagram showing an isochronous inputtransfer between a high-speed host and a full-speed device according tothe invention;

[0201]FIG. 12 is a sequence diagram showing an isochronous outputtransfer between a high-speed host and a full-speed device according tothe invention;

[0202]FIG. 13 is a sequence diagram showing an isochronous inputtransfer between a high-speed host and a high-speed device according tothe invention;

[0203]FIG. 14 is a sequence diagram showing an isochronous outputtransfer between a high-speed host and a high-speed device according tothe invention;

[0204]FIG. 15 is a sequence diagram showing a high bandwidth isochronousinput transfer between a high-speed host and a high-speed deviceaccording to the invention;

[0205]FIG. 16 is a sequence diagram showing a high bandwidth isochronousoutput transfer between a high-speed host and a high-speed deviceaccording to the invention;

[0206]FIG. 17 is a timing diagram showing interrupt transfers accordingto the USB protocol;

[0207]FIG. 18 is a timing diagram showing interrupt transfers accordingto the current invention;

[0208]FIG. 19 is a sequence diagram showing an interrupt input transferbetween a high-speed host and a low-speed device according to theinvention;

[0209]FIG. 20 is a sequence diagram showing an interrupt output transferbetween a high-speed host and a low-speed device according to theinvention;

[0210]FIG. 21 is a sequence diagram showing an interrupt input transferbetween a high-speed host and a high-speed device according to theinvention;

[0211]FIG. 22 is a sequence diagram showing an interrupt output transferbetween a high-speed host and a high-speed device according to theinvention;

[0212]FIG. 23 is a sequence diagram showing a high bandwidth interruptinput transfer between a high-speed host and a high-speed deviceaccording to the invention;

[0213]FIG. 24 is a sequence diagram showing a high bandwidth interruptoutput transfer between a high-speed host and a high-speed deviceaccording to the invention;

[0214]FIG. 25 is a timing diagram showing control and bulk datatransfers according to the USB protocol;

[0215]FIG. 26 is a timing diagram showing control and bulk datatransfers according to the current invention;

[0216]FIG. 27 is a sequence diagram showing a control input transferbetween a high-speed host and a low-speed device according to theinvention;

[0217]FIG. 28 is a sequence diagram showing a control output transferbetween a high-speed host and a low-speed device according to theinvention;

[0218]FIG. 29 is a sequence diagram showing a control input transferbetween a high-speed host and a high-speed device according to theinvention;

[0219]FIG. 30 is a sequence diagram showing a control output transferbetween a high-speed host and a high-speed device according to theinvention;

[0220]FIG. 31 is a sequence diagram showing a bulk input transferbetween a high-speed host and a full-speed device according to theinvention;

[0221]FIG. 32 is a sequence diagram showing a bulk output transferbetween a high-speed host and a full-speed device according to theinvention;

[0222]FIG. 33 is a sequence diagram showing a PING protocol according tothe invention.

DESCRIPTION OF THE DRAWINGS

[0223] In the drawings, FIG. 1 shows a PC (1) connected to four standardUSB Devices (3 a, 3 b, 3 c & 3 d). While the length of cable between thetwo hubs cannot normally exceed 5 meters according to the current USBSpecification, the PC (1) is also equipped with an apparatus accordingto the present invention, which is termed as an “Extended Range Hub”(7). The Extended Range Hub (7) is composed of two separate units, a“Local Expander” (4) or (LEX) and a “Remote Expander” (5) (or REX) whichare connected by cable (6). In one embodiment of the invention, units 4and 5 are separated by, for example, 200 meters of fibre optic cable (6)(although Category 5 UTP wiring or wireless transmission could also beused). This arrangement of devices is identical to the arrangementdescribed earlier in PCT application No. PCT/CA00/00157.

[0224]FIG. 2 illustrates a more schematic diagram of the arrangementdescribed in FIG. 1. The functions normally provided by a standard USB2.0 Hub are provided by two separate units (4 & 5) connected by a lengthof fibre optic cable (6). In this representation, the REX unit (5)consists of two main components—the REX-FPGA (8) and a standard USB 2.0Hub (9). The REX-FPGA (8) component represents a Field Programmable GateArray (FPGA) as well as other hardware components. The standard USB 2.0Hub is hereinafter referred to as the REX-Hub(9). The REX-FPGA (8) isconnected to the LEX by a fibre optic cable (6), but might also beconnected by UTP (Unshielded Twisted Pair) cable or wiring. The REX-Hub(9) is connected to the REX-FPGA (8) within the REX unit (5) and saidREX-Hub (9) would operate in the same manner whether connected to theREX-FPGA (8) or directly to the Host PC (1) (which might also be astandard USB hub). The REX-Hub (9) is connected to a plurality of USBdevices. In this embodiment said plurality is chosen to be four, but itwill be clear to those skilled in the art that other choices may be madewithin the scope of the invention.

[0225] Operation over extended distances is preferably achieved byplacing said LEX unit (4) close to said host PC (1), placing said REXunit (5) close to said plurality of USB (3 a, 3 b, 3 c and/or 3 d)devices, and connecting LEX unit (4) and REX unit (5) by the requiredextended length of fibre optic cabling (6).

[0226]FIG. 3 provides a prior art timing diagram showing isochronoustransfers according to the USB protocol. The diagram is constructed fromthe point of view of a USB Host Controller (1), normally included on aPC motherboard (Host PC). The USB protocol divides time allocation onthe shared bus into regular intervals. The duration in time of eachinterval is represented by “t” in FIG. 3 and the duration of eachinterval will be represented by “t” hereinafter. The start of eachtransaction interval is identified on the diagram as I1, I2, I3, I4. Fora full-speed host, the time allotted for each interval is 1 ms and suchintervals are hereinafter referred to as frames. For a high-speed host,the time allotted for each interval is 125 _(μ)s and such intervals arehereinafter referred to as microframes. Eight microframes are equivalentto one frame.

[0227] When a Host Controller (1) is engaged upon an isochronoustransfer with a device (3), the Host Controller (1) issues regularrequests for data transfer to said device (3). These requests areidentified as packets R1, R2, and R3 (10, 12, & 14). Under the USBprotocol, a USB device (3) must respond to the request from a full-speedhost within 16 full-speed bit-times. In response to requests from ahigh-speed host, a USB device must respond within 736 high-speedbit-times. The responses are shown in the diagram as packets Is1, Is2,and Is3 (11, 13, & 15). It is commonly expected that transfer Is1 (11)will be delivered in response to request R1 (10) within the sameinterval, transfer Is2 (13) will be delivered in response to request R2(12) within the same interval, and so on until the requests areterminated.

[0228]FIG. 4 provides a timing diagram showing isochronous transfersaccording to the present invention, which is, however, essentiallyidentical to the isochronous transfer described in PCT/CA00/00157 forfull-speed transfers. The diagram shows the progression of packetsthrough the various subsystems comprising the invention. Timelines arepresented for the Host PC (1), Local Expander (4) and Remote ExpanderFPGA (8) components that are shown in FIG. 1.

[0229] An isochronous transfer is initiated from a Host.PC (1) byemitting a request for input data R1 (20) to a particular USB addressand end-point. Said request R1 (20) is received by the LEX (4) andretransmitted as R1 (25) over the external cabling to the REX-FPGA (8).Said retransmitted packet R1 (31) is received by the REX-FPGA andforwarded to the REX-Hub (9).

[0230] The target device generates an input data packet Is1 (32).According to the USB protocol for low-speed and full-speed isochronoustransfers, a device with a detachable cable must generate a responsewithin 6.5 bit-times of the end of the corresponding request. Forhigh-speed isochronous transfers, a device must generate a responsewithin 192 high-speed bit times. Said input data packet Is1 (32) isreceived by the REX-Hub (9) and the REX-FPGA subsystem (8) andretransmitted as Is1 (26), over the external wiring, to the LEX. Saidretransmitted response Is1 (26) is not immediately forwarded to the HostPC, but is stored within the memory of the LEX subsystem.

[0231] The Host PC (1) notices that it did not receive a response to itsinput data request R1 (20) and retries the transaction by generating afurther request R2 (21) to the same USB address and end-point. Uponreceiving request R2 (21), the LEX subsystem retrieves response Is1 (26)from its memory buffers and forwards it to the Host PC as response Is1(22).

[0232] Said second request R2 (21) is repeated as R2 (27) through theLEX and forwarded as R2 (33) to the device. The target device generatesa second response Is2 (34) which is retransmitted as Is2 (28) by theREX-FPGA to the LEX. Response Is2 (28) is again stored within the memoryof the LEX subsystem, from where it is sent to the Host PC (1) asresponse Is2 (24) to a third request R3 (23). The process is repeated asnecessary with request R3 (23), R3 (29) and R3 (35) and response Is3(36) and Is3 (30).

[0233]FIG. 5 is a block diagram of an embodiment of a LEX (LocalExpander) (4) according to the invention. In this embodiment, the USB2.0 Transceiver (50) is connected to a USB host by conventional means,signified by the standard USB signals D+ and D−.

[0234] Data signals from the USB host are received by Link Transceiver(50) and stored in the Dual FIFO (53). The Microprocessor (51) isalerted through the control channel from the transceiver that new datahas arrived and is available in the FIFO. The Microprocessor (51)instructs the Router (54) to route the data according to predefinedrouting tables. The Router then copies the data from the Dual FIFO (53)to the appropriate destination, either Dual FIFO (55) or Buffer (56). Inthe situation where the data is required to be absorbed, then the Routerremoves the data from dual FIFO (53) and discards said data. When datais copied to Dual FIFO (55), said data is transmitted over the extendedrange link by Link Transceiver (52) as D_(d) and D_(u).

[0235] If the treatment of the received data is not already defined bythe routing tables, the Router (54) passes said received data to theMicroprocessor (51) for analysis. After inspecting said data, theMicroprocessor (51) updates the routing tables and returns control tothe Router (54).

[0236] A similar process occurs in the reverse direction when data isreceived from the extended range link by Link Transceiver (52). Saidreceived data is automatically copied to Dual FIFO (55) from where it istransferred to Buffer (56) or Dual FIFO (53) by Router (54) under thecontrol of Microprocessor (51). Data so transferred to Dual FIFO (53) istransmitted to the USB host by USB 2.0 Transceiver (50).

[0237]FIG. 6 is a block diagram of an embodiment of a REX-FPGA accordingto the invention. The REX-FPGA (8) is connected to the extended rangelink (6) by Link Transceiver (60). The REX-FPGA is connected to REX-Hub(9) by USB 2.0 Transceiver (62) using conventional USB signals D+ andD−.

[0238] Data signals as D_(d) and D_(u), are received from extended rangelink (6) by Link Transceiver (60) and stored in Dual FIFO (63). TheMicroprocessor (61) is alerted through the control channel from thetransceiver that new data has arrived and is available in the FIFO. TheMicroprocessor instructs the Router (64) to route the data according topredefined routing tables. The Router then copies the data from the DualFIFO (63) to the appropriate destination, either Dual FIFO (65) orBuffer (66). If the data is required to be absorbed, then the Routerremoves the data from Dual FIFO (63) and discards said data. When datais copied to Dual FIFO (65), said data is transmitted to the Rex-Hub byUSB 2.0 Transceiver (62)

[0239] If the treatment of the received data is not already defined bythe routing tables, the Router passes said received data to theMicroprocessor for analysis. After inspecting said data, theMicroprocessor updates the routing tables and returns control to theRouter.

[0240] A similar process occurs in the reverse direction when data isreceived from the Rex-Hub by USB 2.0 Transceiver (62). Said receiveddata is automatically copied to Dual FIFO (65) from where it istransferred to Buffer (66) or Dual FIFO (63) by Router (64) under thecontrol of Microprocessor (61). Data so transferred to Dual FIFO (63) istransmitted to the extended range link by Link Transceiver (60).

[0241]FIG. 7 provides a sequence diagram showing an isochronous inputtransfer, between a full-speed host and a full-speed device. In Frame 1,a request for input data is transmitted from the Host control logic(100) and said request is received by the LEX subsystem as an IN packet.The control logic (101) within the LEX subsystem forwards the IN packetto the REX-FPGA subsystem. The control logic (102) within the REX-FPGAsubsystem forwards the IN packet to the REX-Hub. The control logic (103)within the REX-Hub forwards the IN packet to the Device.

[0242] The control logic (104) within the device assembles the requestedisochronous data and transmits said data as a Result packet to theREX-Hub. The control logic (103) within the REX-Hub forwards the Resultpacket to the REX-FPGA subsystem. The control logic (102) within theREX-FPGA subsystem forwards the Result packet to the LEX subsystem. Thecontrol logic (101) in the LEX subsystem stores the Result packet in itsbuffer memory.

[0243] In Frame 2, the control logic (105) within the Host recognizesthat it has not received a response to its previous request for inputdata and it automatically retries the transaction by generating afurther request addressed to the same USB function as in Frame 1. Saidfurther request is transmitted to the LEX subsystem as a second INpacket. On receipt of the second IN packet, the control logic (106)within the LEX subsystem recognizes that it has a Result packet storedin memory from the same function identified by the further IN packet andtransmits said Result packet to the host Said control logic (106) alsoforwards the further IN packet to the REX-FPGA subsystem. The controllogic (107) within the REX-FPGA subsystem forwards said IN packet to theREX-Hub. The control logic (108) within the REX-Hub forwards the INpacket to the Device.

[0244] The control logic (109) within the device assembles the requestedisochronous data and transmits it as a Result packet to the REX-Hub. Thecontrol logic (108) within the REX-Hub forwards the Result packet to theREX-FPGA subsystem. The control logic (107) within the REX-FPGAsubsystem forwards said Result packet to the LEX subsystem. The controllogic (106) in the LEX subsystem stores the Result packet in its buffermemory.

[0245] The above-described process is repeated for subsequent frames bythe distributed control logic (e.g. 105, 106, 107, 108, 109).

[0246]FIG. 8 provides a sequence diagram showing an isochronous outputtransfer, between a full-speed host and a full-speed device. In Frame 1,the control logic (100) within the Host generates a notification ofoutput data, addressed to a particular USB function. Said notificationis transmitted to the LEX subsystem as an OUT packet. The control logic(101) within the LEX subsystem forwards said OUT packet to the REX-FPGAsubsystem. The control logic (102) within the REX-FPGA subsystemforwards said OUT packet to the REX-Hub. The control logic (103) withinthe REX-Hub forwards said OUT packet to the Device. The information isreceived by the control logic within the device.

[0247] The control logic (100) within the Host assembles the notifiedisochronous data and transmits it as a Data0 packet to the LEXsubsystem. The control logic (101) within the LEX subsystem forwards theData0 packet to the REX-FPGA subsystem. The control logic (102) withinthe REX-FPGA subsystem forwards said Data0 packet to the REX-Hub. Thecontrol logic (103) within the REX-Hub forwards said Data0 packet to thedevice. The information is received by the control logic (104) withinthe device.

[0248] The above-described process is repeated for subsequent frames bythe distributed control logic (e.g. 100, 101, 102, 103, 104).

[0249]FIG. 9 provides an algorithm for implementing isochronous inputtransfers, between a full-speed host and a full-speed device, at theLocal Expander and Remote Expander. Said algorithm is implemented inhardware by the LEX and REX-FPGA Controllers. According to theinvention, the algorithm of LEX controller is required to implement theprocessing functions represented by processing blocks (101) and (106) ofFIG. 7. The algorithm of REX controller is required to implement theprocessing functions represented by processing blocks (102) and (107) ofFIG. 7.

[0250] According to said algorithm programmed in the LEX controller, ifthe received packet is of type IN then an identical packet istransmitted to the REX-FPGA controller. The LEX controller then examinesits buffer memory to determine whether a stored Result packet from thedevice addressed by the IN request is already present in memory. If nosuch stored Result packet is present in memory, the system then becomesidle. If said stored Result packet is present in memory, the systemretrieves said stored packet from memory and sends said packet to thehost as a packet of type Result. If the received packet is of typeResult then the packet is stored in the buffer memory.

[0251] According to said algorithm programmed in the REX-FPGAcontroller, if the received packet is of type IN then an identicalpacket is forwarded to the REX hub. If the received packet is of typeResult, then the packet is transmitted to the LEX controller.

[0252]FIG. 10 provides an algorithm for implementing isochronous outputtransfers, between a full-speed host and a full-speed device, at theLocal Expander and the Remote Expander. According to the invention, thealgorithm of the LEX controller is required to implement the processingfunctions represented by processing block (101) of FIG. 8. The algorithmof the REX-FPGA controller is required to implement the processingfunctions represented by the processing block (102) of FIG. 8.

[0253] According to the said algorithm, if the received packet at theLEX controller is of type OUT or DATA0, then said packet is forwarded tothe REX-FPGA controller. If the received packet at the REX-FPGAcontroller is of type OUT or DATA0 then said packet is transmitted tothe REX hub.

[0254] The production of the algorithms shown In FIGS. 9 and 10 areconsidered to be easily prepared by the skilled artisan once thesequence diagram is understood. Accordingly, the algorithms for theremaining sequence drawings will not be produced.

[0255]FIG. 11 provides a sequence diagram showing an isochronous inputtransfer, between a high-speed host and a full-speed device. In the lastmicroframe of the previous frame, (Y-1)₇, a start split-transaction anda request for input data are transmitted from the Host control logic(120). Said start split-transaction and the request for input data arereceived by the LEX subsystem as a SSPLIT packet and an IN packet(SSPLIT/IN packets). The control logic (121) within the LEX subsystemforwards the SSPLIT/IN packets to the REX-FPGA subsystem. The controllogic (122) within the REX-FPGA subsystem forwards said SSPLIT/INpackets to the REX-Hub.

[0256] In the first microframe of the current frame, Y₀, the controllogic (128) within the REX-Hub absorbs said SSPLIT packet and forwardssaid IN packet to the Device. The control logic (129) within the deviceassembles the requested isochronous data packet and transmits the sameto the REX-Hub as a continuous stream of data. The size of saidisochronous data packet may range from 0 to 1023 bytes, as defined bythe USB Specification. The control logic (133) within the REX-Hub storesup to the first 188 bytes of data as a Result packet in its buffermemory.

[0257] In the next microframe, Y₁, the control logic (131) within theLEX subsystem receives the complete split-transaction and the requestfor input data from the Host control logic (130) as a CSPLIT packet andan IN packet. With no Result packet stored in its buffer memory, thecontrol logic (131) within the LEX subsystem then generates a syntheticdata packet and transmits it as a NYET packet to the Host PC in responseto the request for input data. The control logic (131) within the LEXsubsystem forwards said CSPLIT/IN packets to the REX-FPGA subsystem. Thecontrol logic (132) within the REX-FPGA subsystem forwards saidCSPLIT/IN packets to the REX-Hub. On receipt of said CSPLIT/IN packets,the control logic (133) within the REX-Hub recognizes that it containsin its buffer memory the first portion of the data packet from thedevice. Said control logic retrieves said stored packet and forwards thesame to the REX-FPGA as a Result packet. Said control logic (133) alsoabsorbs said CSPLIT/IN packets. The control logic (132) within theREX-FPGA subsystem forwards the Result packet to the LEX subsystem. Thecontrol logic (131) in the LEX subsystem stores the Result packet in itsbuffer memory.

[0258] The control logic (138) within the REX-Hub stores up to the next188 bytes of the remaining data from the device as a Result packet inits buffer memory.

[0259] In the subsequent microframe, Y₂, the control logic (136) withinthe LEX subsystem receives the subsequent CSPLIT/IN packets from thecontrol logic (135) within the Host. The control logic (136) within theLEX subsystem forwards the stored Result packet, received in theprevious microframe, to the Host and forwards said CSPLIT/IN packets tothe REX-FPGA subsystem. The control logic (137) within the REX-FPGAsubsystem forwards the CSPLIT/IN packets to the REX-Hub. On receipt ofsaid CSPLIT/IN packets, the control logic (138) within the REX-Hubrecognizes that it contains the second portion of the data packet fromthe device stored in its buffer memory. Said control logic retrievessaid stored packet and forwards the same to the REX-FPGA as a Resultpacket. Said control logic (138) also recognizes that said CSPLIT/INpackets are merely a repetition of the previous CSPLIT/IN packet andabsorbs said packets. The control logic (138) within the REX-Hubforwards the Result packet to the REX-FPGA subsystem. The control logic(137) within the REX-FPGA subsystem forwards the Result packet to theLEX subsystem. The control logic (136) in the LEX subsystems stores theResult packet in its buffer memory.

[0260] The above-described process is repeated until all the datagenerated by the device is transmitted to the host by the distributedcontrol logic (e.g. 135, 136, 137, 138, 139). The process described bythe distributed control logic (120) to (139) is also repeated forsubsequent frames.

[0261] In FIG. 11, a dotted line is also shown between the device andthe REX-Hub. This dotted line is used to represent the total data flowfrom the device to the REX-Hub, even though in this case, the REX-Hubinterprets the receipt of data as being three data transmissions. Insubsequent figures, this dotted line will be used to represent the totaldata transmission even though the various devices or hubs may treat thetransmission as a series of data transmissions.

[0262]FIG. 12 provides a sequence diagram showing an isochronous outputtransfer, between a high-speed host and a full-speed device. In the lastmicroframe of the previous frame, Microframe (Y-1)₇, the control logic(120) within the Host generates a start split-transaction (begin), anotification of output data, and a data packet to the LEX subsystem.Said data packet may contain a maximum of 188 bytes of data. Said startsplit-transaction, notification of output data, and data packet aretransmitted to the LEX subsystem as an SSPLIT-begin packet, an OUTpacket, and a DATA0 packet, respectively. The control logic (121) withinthe LEX subsystem forwards said SSPLIT-begin/OUT/DATA0 packets to theREX-FGPA subsystem. The control logic (122) within the REX-FPGAsubsystem forwards said SSPLIT-begin/OUT/DATA0 packets to the REX-Hub.On receipt of said SSPLIT-begin/OUT/DATA0 packets, the control logic(123) within the REX-Hub absorbs said SSPLIT-begin/OUT packets andstores said DATA0 packet in its buffer memory.

[0263] In the first microframe of the current frame, Microframe Y₀, thecontrol logic (128) within the REX-Hub generates a notification ofoutput data and forwards the same to the Device as an OUT packet. At thesame time, the control logic (125) within the host generates a startsplit-transaction (mid), a notification of output data, and a datapacket and transmits the same to the LEX subsystem asSSPLIT-mid/OUT/DATA0 packets. Said data packet may contain a maximum of188 bytes of data. The control logic (126) within the LEX subsystemforwards said SSPLIT-mid/OUT/DATA0 packets to the REX-FPGA subsystem.The control logic (127) within the REX-FPGA subsystem forwards saidSSPLIT-mid/OUT/DATA0 packets to the REX-Hub. On receipt of saidSSPLIT-mid/OUT/DATA0 packets, the control logic (128) within the REX-Hubbegins forwarding the stored data packet received in the previousmicroframe to the device. Said control logic also absorbs saidSSPLIT-mid/OUT packets and stores the further data packet in its buffermemory.

[0264] In the subsequent microframe, Microframe Y₁, the control logic(130) within the host generates a start split-transaction, anotification of output data, and a data packet and transmits the same tothe LEX subsystem as SSPLIT-mid/OUT/DATA0 packets. Said data packet maycontain a maximum of 188 bytes of data. The control logic (131) withinthe LEX subsystem forwards said SSPLIT-mid/OUT/DATA0 packets to theREX-FPGA subsystem. The control logic (132) within the REX-FPGAsubsystem forwards said SSPLIT-mid/OUT/DATA0 packets to the REX-Hub. Onreceipt of said SSPLIT-mid/OUT/DATA0 packets, the control logic (133)within the REX-Hub begins forwarding the stored data packet received inthe previous microframe to the device. The control logic (134) withinthe device receives the first byte of said stored data packetimmediately after receiving the last byte of the data packet sent fromthe previous frame. The control logic within the REX-Hub transmits datapackets to the device in such a manner that the device receives acontinuous data stream. The control logic (133) within the REX-Hub alsoabsorbs said SSPLIT-mid/OUT packets and stores said further data packet.

[0265] The above-described process is repeated until the host controllertransmits the last output data packet by the distributed control logic(e.g. 130, 131,132, 133, 134). The process described by the distributedcontrol logic (120) to (134) is also repeated for subsequent frames.

[0266]FIG. 13 provides a sequence diagram showing an isochronous inputtransfer, between a high-speed host and a high-speed device. InMicroframe Y₀, a request for input data is transmitted from the Hostcontrol logic (150) and said request is received by the LEX subsystem asan IN packet. The control logic (151) within the LEX subsystem forwardsthe IN packet to the REX-FPGA subsystem. The control logic (152) withinthe REX-FPGA subsystem forwards said IN packet to the REX-Hub. Thecontrol logic (153) within the REX-Hub forwards said IN packet to theDevice.

[0267] The control logic (154) within the device assembles the requestedisochronous data and transmits it as a Result packet to the REX-Hub. Thecontrol logic (153) within the REX-Hub forwards the Result packet to theREX-FPGA subsystem. The control logic (152) within the REX-FPGAsubsystem forwards the Result packet to the LEX subsystem. The controllogic (151) in the LEX subsystem stores the Result packet in its buffermemory.

[0268] In Microframe Y₁, the control logic (155) within the Hostrecognizes that it has not received a response to its previous requestfor input data and it automatically retries the transaction bygenerating a further request addressed to the same USB function as inMicroframe Y₀. Said further request is transmitted to the LEX subsystemas a second IN packet. On receipt of the second IN packet, the controllogic (156) within the LEX subsystem recognizes that it has a Resultpacket stored in memory from the same function identified by the furtherIN packet and transmits said packet to the host. Said control logic(156) also forwards the further IN packet to the REX-FPGA subsystem. Thecontrol logic (157) within the REX-FPGA subsystem forwards said INpacket to the REX-Hub. The control logic (158) within the REX-Hubforwards said IN packet to the Device.

[0269] The control logic (159) within the device assembles the requestedisochronous data and transmits it as a Result packet to the REX-Hub. Thecontrol logic (158) within the REX-Hub forwards said Result packet tothe REX-FPGA subsystem. The control logic (157) within the REX-FPGAsubsystem forwards said Result packet to the LEX subsystem. The controllogic (156) in the LEX subsystem stores said Result packet in its buffermemory.

[0270] The above-described process is repeated for subsequentmicroframes by the distributed control logic (e.g. 155,156, 157, 158,159).

[0271]FIG. 14 provides a sequence diagram showing an isochronous outputtransfer, between a high-speed host and a high-speed device. InMicroframe Y₀, the control logic (150) within the Host generates anotification of output data, addressed to a particular USB function.Said notification is transmitted to the LEX subsystem as an OUT packet.The control logic (151) within the LEX subsystem forwards said OUTpacket to the REX-FPGA subsystem. The control logic (152) within theREX-FPGA subsystem forwards said OUT packet to the REX-Hub. The controllogic (153) within the REX-Hub forwards said OUT packet to the Device.The information is received by the control logic within the device.

[0272] The control logic (150) within the Host assembles the notifiedisochronous data and transmits it as a DATA0 packet to the LEXsubsystem. The control logic (151) within the LEX subsystem forwardssaid DATA0 packet to the REX-FPGA subsystem. The control logic (152)within the REX-FPGA subsystem forwards said DATA0 packet to the REX-Hub.The control logic (153) within the REX-Hub forwards said DATA0 packet tothe device. The information is received by the control logic (154)within the device.

[0273] The above-described process is repeated for subsequentmicroframes by the distributed control logic (e.g. 150, 151, 152, 153,154).

[0274]FIG. 15 provides a sequence diagram showing a high-bandwidthisochronous input transfer, between a high-speed host and a high-speeddevice. In Microframe Y₀, the control logic (170) in the Host PCgenerates a request for input data. Said request for input data istransmitted to the LEX subsystem as an IN packet. The control logic(171) within the LEX subsystem generates a synthetic data packet andtransmits it as a NULL packet to the Host in response to the input datarequest. The control logic (171) within the LEX subsystem forwards theIN packet to the REX-FPGA subsystem. The control logic (172) within theREX-FPGA subsystem forwards said IN packet to the REX-Hub. The controllogic (173) within the REX-Hub forwards said IN packet to the Device.

[0275] The control logic (174) within the device assembles the requestedisochronous data and transmits it as a Result_1_1 packet to the REX-Hub.The control logic (173) within the REX-Hub forwards the Result_1_1packet to the REX-FPGA subsystem. The control logic (172) within theREX-FPGA subsystem forwards the Result_1_1 packet to the LEX subsystem.The control logic (171) in the LEX subsystem stores the Result_1_1packet in its buffer memory.

[0276] On receipt of the first NULL packet generated by the LEXsubsystem, the control logic (170) within the Host generates a secondrequest for input data within the same microframe, Y₀. Said request forinput data is transmitted to the LEX subsystem as an IN packet. Thecontrol logic (171) within the LEX subsystem generates a secondsynthetic data packet and transmits it as a NULL packet to the Host. Thesecond IN packet is forwarded to the device in the same manner as thefirst IN packet.

[0277] On receipt of the second IN packet, the control logic (174)within the device assembles the requested isochronous data and transmitsit as a Result_1_2 packet to the REX-Hub. The Result_1_2 packet istransmitted to the LEX subsystem in the same manner as the Result_1_1packet and it is also stored in the buffer memory of the LEX subsystem.

[0278] On receipt of the second NULL packet generated by the LEXsubsystem, the control logic (170) within the Host generates a thirdrequest for input data within the same microframe, Y₀. Said request forinput data is transmitted to the LEX subsystem as an IN packet. Thecontrol logic (171) within the LEX subsystem generates a third syntheticdata packet and transmits it as a NULL packet to the Host. The third INpacket is forwarded to the device in the same manner as the first andsecond IN packet.

[0279] On receipt of the third IN packet, the control logic (174) withinthe device assembles the requested isochronous data and transmits it asa Result_1_3 packet to the REX-Hub. The Result_1_3 packet is transmittedto the LEX subsystem in the same manner as the Result_1_1 and Result_1_2packets and it is also stored in the buffer memory of the LEX subsystem.

[0280] In Microframe Y₁, the control logic (175) within the Hostgenerates a request for input data and transmits said request as an INpacket to the LEX subsystem. The control logic (176) within the LEXsubsystem forwards the first stored result packet, Result_1_1, to theHost in response to the input data request. The control logic (176)within the LEX subsystem forwards said IN packet to the REX-FPGAsubsystem. The control logic (177) within the REX-FPGA subsystemforwards said IN packet to the REX-Hub. The control logic (178) withinthe REX-Hub forwards said IN packet to the Device.

[0281] On receipt of said IN packet, the control logic (179) within thedevice assembles the requested isochronous data and transmits it as aResult_2_1 packet to the REX-Hub. The control logic (178) within theREX-Hub forwards the Result_2_1 packet to the REX-FPGA subsystem. Thecontrol logic (177) within the REX-FPGA subsystem forwards theResult_2_1 packet to the LEX subsystem. The control logic (176) withinthe LEX subsystem stores the Result_2_1 packet in its buffer memory.

[0282] Within the same microframe, Y₁, the control logic (175) withinthe Host generates a second request for input data and transmits saidrequest as an IN packet to the LEX subsystem. The control logic (176)within the LEX subsystem forwards the second stored result packet,Result_1_2, to the Host In response to the input data request. Said INpacket is forwarded to the device in the same manner as the previous INpacket.

[0283] On receipt of the second IN packet, the control logic (179)within the device assembles the requested isochronous data and transmitsit as a Result_2_2 packet to the REX-Hub. The Result_2_2 packet istransmitted to the LEX subsystem in the same manner as the Result_2_1packet and it is stored in the buffer memory of the LEX subsystem.

[0284] Within the same microframe, Y₁, the control logic (175) withinthe Host generates a third request for input data and transmits saidrequest as an IN packet to the LEX subsystem. The control logic (176)within the LEX subsystem forwards the third stored result packet,Result_1_3, to the Host in response to the input data request. Said INpacket is forwarded to the device in the same manner as the previous INpacket.

[0285] On receipt of the third IN packet, the control logic (179) withinthe device assembles the requested isochronous data and transmits it asa Result_2_3 packet to the REX-Hub. The Result_2_3 packet is transmittedto the LEX subsystem in the same manner as the Result_2_1 and Result_2_2and it is stored in the buffer memory of the LEX subsystem.

[0286] The above-described process is repeated for subsequentmicroframes by the distributed control logic (e.g. 175, 176, 177, 178,179).

[0287]FIG. 16 provides a sequence diagram showing a high-bandwidthisochronous output transfer, between a high-speed host and a high-speeddevice. In Microframe Y₀, the control logic (170) within the Hostgenerates a notification of output data addressed to a particular USBfunction. Said notification is transmitted to the LEX subsystem as anOUT packet. The control logic (171) within the LEX subsystem forwardssaid OUT packet to the REX-FPGA subsystem. The control logic (172)within the REX-FPGA subsystem forwards said OUT packet to the REX-Hub.The control logic (173) within the REX-Hub forwards said OUT packet tothe Device. The information is received by the control logic within thedevice.

[0288] The control logic (170) within the Host assembles the notifiedisochronous data and transmits it as an MData packet to the LEXsubsystem. The control logic (171) within the LEX subsystem forwardssaid MData packet to the REX-FPGA subsystem. The control logic (172)within the REX-FPGA subsystem forwards said MDATA packet to the REX-Hub.The control logic (173) within the REX-Hub forwards said MDATA packet tothe device. The information is received by the control logic (174)within the device.

[0289] Within the same microframe, Y₀, the control logic (170) withinthe Host generates a second notification of output data. Saidnotification is transmitted to the LEX subsystem as an OUT packet and istransmitted to the device in the same manner as the previous OUT packet.The control logic (170) within the Host then assembles the notifiedisochronous data and transmits it as a second MDATA packet to the LEXsubsystem. Said MDATA packet is transmitted to the device in the samemanner as the previous MDATA packet.

[0290] In the same microframe, Y₀, the control logic (170) within theHost generates a third notification of output data. Said notification istransmitted to the LEX subsystem as an OUT packet and is transmitted tothe device in the same manner as the previous OUT packet. The controllogic (170) within the Host then assembles the notified isochronous dataand transmits the same as a DATA0 packet to the LEX subsystem. Thecontrol logic (171) within the LEX subsystem forwards said DATA0 packetto the REX-FPGA subsystem. The control logic (172) within the REX-FPGAsubsystem forwards said DATA0 packet to the REX-Hub. The control logic(173) within the REX-Hub forwards said DATA0 packet to the device. Theinformation is received by the control logic (174) within the device.

[0291]FIG. 17 provides a simplified timing diagram showing interrupttransfers, a special case of asynchronous transfers, according to theprior art USB protocol. The diagram is constructed from the point ofview of a USB Host Controller, normally included on a PC motherboard(Host PC). The USB protocol divides time allocation on the shared businto regular intervals. The start of each interval is again identifiedon the diagram as I1, I2, I3, I4. For a full-speed host, each intervalis 1 ms in duration and Is again referred to as a frame. For ahigh-speed host, each interval is 125 _(μ)s in duration and is referredto as a microframe.

[0292] When a Host Controller is engaged upon an interrupt transfer witha device, the Host Controller issues regular requests for data transferto said device. These requests are identified as packets R1, R2, and R3(10, 13, & 17). Under the USB protocol, a USB device must respond to therequest from a full-speed host within 16 full-speed bit-times. Inresponse to requests from a high-speed host, a USB device must respondwithin 736 high-speed bit-times. The responses are shown in the diagramas packets In1, In2, and In3 (11, 14, & 18). On receipt of a responsepacket, the Host Controller also emits an acknowledgement and theseacknowledgements are identified as packets K1, K2, K3 (12, 15, & 19). Itis commonly expected that transfer In1 (11) will be delivered inresponse to request R1 (10) and acknowledgement K1 (12) will be emittedon receipt of In1 (11) within the same interval, transfer In2 (14) willbe delivered in response to request R2 (13) and acknowledgement K2 (15)will be emitted on receipt of In2 (14) within the same interval, and soon until the requests are terminated.

[0293]FIG. 18 provides a simplified timing diagram showing interrupttransfers, a special case of asynchronous transfers, which isessentially identical to the system described in PCT/CA00/00157, forfull-speed hosts and/or devices. The diagram shows the progression ofpackets through the various subsystems comprising the invention. Timelines are presented for the Host PC (1), Local Expander (4) and RemoteExpander FPGA (8) subsystems as shown in FIG. 2.

[0294] An interrupt transfer is initiated from a Host PC (1) by emittinga request for input data R1 (20) to a particular USB address andend-point. Said request R1 (20) is received by the LEX and retransmittedas R1 (25) over the external cabling to the REX-FPGA (8). Saidretransmitted packet R1 (25) is received by the REX-FPGA and forwardedas R1 (32) to the REX-Hub (9). A synthetic negative acknowledgementpacket is generated by the LEX (4) and transmitted as N1 (26) to thehost.

[0295] The target device generates an input data packet In1 (33).According to the USB protocol for low-speed and full-speed isochronoustransfers, a device with a detachable cable must generate a responsewithin 6.5 full-speed bit-times of the end of the corresponding request.For high-speed isochronous transfers, a device must generate a responsewithin 192 high-speed bit times. Said input data packet In1 (33) isreceived by the REX-Hub (9) and the REX-FPGA (8) subsystem andretransmitted as In1 (27) over the external wiring to the LEX (4). Saidretransmitted response In1 (27) is not immediately forwarded to the HostPC (1), but is stored within the memory of the LEX subsystem (4). Asynthetic acknowledgement packet K1 (34) is generated by the REX-FGPAsubsystem (8) and transmitted as K1 (34) to the REX-Hub (9).

[0296] The Host PC (1) notices that it did not receive data in responseto its request R1 (20), and retries the transaction by generating afurther request R2 (22) to the same USB address and end-point. Uponreceiving request R2 (28), the LEX subsystem retrieves response In1 (27)from its memory buffers and forwards it to the Host PC (1) as responseIn1 (29). Said response is received by the Host as response In1 (23).Upon receiving said response In1 (23), the Host generates anacknowledgement packet and transmits the packet as packet K1 (24) to theLEX subsystem (4). Said acknowledgement packet K1 (30) is received andabsorbed by LEX.

[0297] Said second request R2 (22) is repeated as R2 (28) through theLEX and forwarded as R2 (35) to the device. The target device generatesa second response In2 (36) which is transmitted as In2 (31) to the LEX.Said retransmitted response In2 (31) is stored in the memory of the LEXsubsystem. A synthetic acknowledgement packet is generated by theREX-FPGA subsystem and transmitted to the REX-Hub. The protocol sequenceis repeated as necessary.

[0298]FIG. 19 provides a sequence diagram showing an interrupt inputtransfer, between a high-speed host and a full-speed or low-speeddevice. In the microframe before the current frame, Microframe (Y-1)₇,the control logic (240) within the Host generates a startsplit-transaction followed by a request for input data, addressed to aparticular USB function. Said split-transaction and request aretransmitted to the LEX subsystem as an SSPLIT packet and an IN packet(SSPLIT/IN packets). The control logic (241) within the LEX subsystemforwards the SSPLIT/IN packets to the REX-FPGA subsystem. The controllogic (242) within the REX-FPGA subsystem forwards said SSPLIT/INpackets to the REX-Hub. The control logic (243) within the REX-Hubabsorbs said SSPLIT packet. In the first microframe of the currentframe, Microframe Y₀, the control logic (248) within the REX-Hubforwards said IN packet to the Device. The control logic (249) withinthe device assembles the requested interrupt data and transmits the sameas a Result packet to the REX-Hub.

[0299] In the next microframe, Microframe Y₁, the control logic (250) inthe Host recognizes that it has not received a response to its previousrequest for input data. Said control logic automatically retries thetransaction by generating a complete split-transaction followed by afurther request addressed to the same USB function as in Microframe(Y-1)₇. Said split-transaction and further request are transmitted tothe LEX subsystem as a CSPLIT packet and an IN packet (CSPLIT/INpackets). On receipt of said CSPLIT/IN packets, the control logic (251)within the LEX subsystem recognizes the lack of data that corresponds tothe Input request in its buffer memory. Said control logic (251) thengenerates a NYET packet to the Host. Said NYET packet warns the Hostthat the LEX subsystem has not yet received a response from the deviceand enables said Host to progress to the next transaction. Said controllogic (251) also forwards the CSPLIT/IN packets to the REX-FPGAsubsystem. The control logic (252) within the REX-FPGA subsystemforwards said CSPLIT/IN packets to the REX-Hub.

[0300] The control logic (253) within the REX-Hub receives the Resultpacket from the device and forwards said Result packet to the REX-FPGAsubsystem. On receipt of said Result packet, the control logic (252)within the REX-FPGA subsystem generates a synthetic acknowledgementpacket which is transmitted as an ACK packet to the REX-Hub. The controllogic (253) within the REX-Hub forwards said ACK packet to the Device.The control logic (252) within the REX-FPGA subsystem forwards saidResult packet to the LEX subsystem and the control logic (251) withinthe LEX subsystem stores said result packet in its buffer memory.

[0301] In the next microframe, Microframe Y₂, the control logic (255) inthe Host recognizes that it has not received the requested data andautomatically retries the transaction by generating a further completesplit-transaction and a further request addressed to the same USBfunction as in Microframe Y₁. The complete split-transaction and requestfor input data are transmitted to the LEX subsystem as CSPLIT/INpackets. On receipt of the CSPLIT/IN packets, the control logic (256)within the LEX subsystem recognizes that it has a Result packet storedin memory from the same function identified by the further CSPLIT/INpackets. Said control logic retrieves said stored Result packet frommemory and transmits said stored packet to the Host. Said control logicalso recognizes that said CSPLIT/IN packets are merely a repetition ofthe previous CSPLIT/IN packets and absorbs said packets. When thecontrol logic (255) of the Host receives the requested Result packetfrom the LEX, said control logic generates an ACK packet to acknowledgea successful transmission. Upon receipt of the ACK packet from the host,the control logic (256) within the LEX subsystem absorbs said ACKpacket.

[0302]FIG. 20 provides a sequence diagram showing an interrupt outputtransfer, between a high-speed host and a full speed or low-speeddevice. In Microframe Y₀, the control logic (240) generates a startsplit-transaction, a notification of output data, and output data,addressed to a particular USB function. Said start split-transaction,notification of output data, and output data are transmitted to the LEXsubsystem as an SSPLIT packet, an OUT packet, and a DATAX packet,respectively. Said DATAX packet represents either a DATA0 packet or aDATA1 packet. The control logic (241) within the LEX subsystem forwardssaid SSPLIT/OUT/DATAX packets to the REX-FPGA subsystem. The controllogic (242) within the REX-FPGA subsystem forwards said SSPLIT/OUT/DATAXpackets to the REX-Hub.

[0303] In Microframe Y₁, the control logic (248) within the REX-Hubforwards the OUT packet and DATAX packet to the device. The informationis received by the control logic (249) within the device. On receipt ofsaid DATAX packet, the control logic (249) within the device generatesan acknowledgement and transmits the same to the REX-Hub as a Resultpacket. The control logic (248) within the REX-Hub stores said Resultpacket in its buffer memory.

[0304] In Microframe Y₂, the control logic (250) within the Hostgenerates a complete split-transaction followed by a notification ofoutput data, addressed to the same USB function as in Microframe Y₀.Said complete split transaction and notification of output data aretransmitted to the LEX subsystem as a CSPLIT packet and an OUT packet(CSPLIT/OUT packets). On receipt of said CSPLIT/OUT packets, the controllogic (251) within the LEX subsystem recognizes the lack of data thatcorresponds to the CSPLIT/OUT packets in its buffer memory. Said controllogic (251) then generates a NYET packet to the Host. Said NYET packetwarns the Host that the LEX subsystem has not yet received a responsefrom the device and enables said Host to progress to the nexttransaction. The control logic (251) within the LEX subsystem forwardssaid CSPLIT/OUT packets to the REX-FPGA subsystem. The control logic(252) within the REX-FPGA subsystem forwards said CSPLIT/OUT packets tothe REX-Hub.

[0305] On receipt of the CSPLIT/OUT packets, the control logic (253)within the REX-Hub recognizes that it has a Result packet stored inmemory from the function identified by the SSPLIT/OUT/DATAX packets fromMicroframe Y₀. Said control logic retrieves said stored Result packetfrom memory and transmits the same to the REX-FPGA subsystem. Thecontrol logic (252) within the REX-FPGA subsystem forwards said Resultpacket to the LEX subsystem. The control logic (251) within the LEXsubsystem stores said Result packet in its buffer memory.

[0306] In Microframe Y₃, the control logic (255) within the hostrecognizes that it has not yet received an acknowledgement from thedevice. Said control logic generates a further completesplit-transaction and a further notification of output data, addressedto the same USB function as in the previous microframe. Said completesplit-transaction and notification of output data are transmitted to theLEX subsystem as further CSPLIT/OUT packets. On receipt of theCSPLIT/OUT packets, the control logic (256) within the LEX subsystemrecognizes that it has a Result packet stored in the memory from thefunction identified by the further CSPLIT/OUT packets. Said controllogic retrieves said stored Result packet from memory and transmits thesame to the Host. Said control logic also recognizes that saidCSPLIT/OUT packets are merely a repetition of the previous CSPLIT/OUTpackets and absorbs said packets.

[0307]FIG. 21 provides a sequence diagram showing an interrupt inputtransfer, between a high-speed host and a high-speed device. InMicroframe Y₀, the control logic (260) within the Host generates arequest for input data, addressed to a particular USB function. Saidrequest is transmitted to the LEX subsystem as an IN packet. On receiptof said IN packet, the control logic (261) within the LEX subsystemrecognizes the lack of data that corresponds to the input request in itsbuffer memory. Said control logic (261) then generates a syntheticnegative acknowledgement packet and transmits the same as a NAK packetto the Host. Said NAK packet warns the Host that it will not receive aresponse to its request and enables said Host to progress to the nexttransaction. The control logic (261) within the LEX subsystem forwardsthe IN packet to the REX-FPGA subsystem. The control logic (262) withinthe REX-FPGA subsystem forwards said IN packet to the REX-Hub. Thecontrol logic (263) within the REX-Hub forwards said request for inputdata as an IN packet to the Device. The control logic (264) within thedevice assembles the requested interrupt data and transmits the same asa Result packet to the REX-Hub. The control logic (263) within theREX-Hub forwards the Result packet to the REX-FPGA subsystem. On receiptof said Result packet, the control logic (262) within the REX-FPGAsubsystem generates a synthetic acknowledgement packet that istransmitted as an ACK packet to the REX-Hub.

[0308] The control logic (263) within the REX-Hub forwards said ACKpacket to the Device. The control logic (262) within the REX-FPGAsubsystem forwards said Result packet to the LEX subsystem and thecontrol logic (261) within the LEX subsystem stores said result packetin its buffer memory.

[0309] In Microframe Y₁, the control logic (265) within the Hostrecognizes that it has not received the requested data and automaticallyretries the transaction by generating a further request addressed to thesame USB function as in Microframe Y₀. Said further request istransmitted to the LEX subsystem as a second IN packet On receipt of thesecond IN packet, the control logic (266) within the LEX subsystemrecognizes that it has a Result packet stored in memory from the samefunction identified by the further IN packet. Said control logicretrieves said stored Result packet from memory and transmits the samepacket to the Host When the control logic (265) of the Host receives therequested Result packet from the LEX, said control logic generates anACK packet to acknowledge a successful transmission. Upon receipt of theACK packet from the host, the control logic (266) within the LEXsubsystem absorbs said packet. Said control logic (266) forwards thefurther IN packet to the REX-FPGA subsystem. The control logic (267)within the REX-FPGA forwards said IN packet to the REX-Hub. The controllogic (268) within the REX-Hub forwards said request for input data asan IN packet to the Device.

[0310] The control logic (269) within the device assembles the requestedinterrupt data and transmits the same as a Result packet to the REX-Hub.The control logic (268) within the REX-Hub forwards the Result packet tothe FPGA subsystem. On receipt of said Result packet, the control logic(267) within the REX-FPGA subsystem generates a syntheticacknowledgement packet that is transmitted as an ACK packet to theREX-Hub. The control logic (268) within the REX-Hub forwards said ACKpacket to the Device. The control logic (267) within the REX-FPGAsubsystem forwards said Result packet to the LEX subsystem and thecontrol logic (266) within the LEX subsystem stores said result packetin its buffer memory.

[0311] The above-described process is repeated for subsequent input datarequests from the Host by the distributed control logic (e.g. 265, 266,267, 268, 269).

[0312]FIG. 22 provides a sequence diagram showing an interrupt outputtransfer, between a high-speed host and a high-speed device. InMicroframe Y₀, the control logic (260) within the Host generates anotification of output data followed by output data, addressed to aparticular USB function. Said notification and output data aretransmitted to the LEX subsystem as an OUT packet and a DATAX packet(OUT/DATAX packets). Said DATAX packet represents either a DATA0 packetor a DATA1 packet. On receipt of the OUT/DATAX packets, the controllogic (261) within the LEX subsystem generates a synthetic negativeacknowledgement packet and transmits the same to the Host as a NAKpacket. Said NAK packet warns the Host that it will not receive aresponse to its request and enables said Host to progress to the nexttransaction. The control logic (261) within the LEX subsystem forwardssaid OUT/DATAX packets to the REX-FPGA subsystem. The control logic(262) within the REX-FPGA subsystem forwards said OUT/DATAX packets tothe REX-Hub. The control logic (263) within the REX-Hub forwards saidOUT/DATAX packets to the Device. The information is received by thecontrol logic within the device.

[0313] On receipt of the OUT/DATAX packets, the control logic (264)within the device generates an acknowledgement and transmits the same asa Result packet to the REX-Hub. The control logic (263) within theREX-Hub forwards said Result packet to the REX-FPGA subsystem. Thecontrol logic (262) within the REX-FPGA subsystem forwards said Resultpacket to the LEX subsystem. The control logic (261) within the LEXsubsystem stores said Result packet in its buffer memory.

[0314] In Microframe Y₁, the control logic (265) within the Hostrecognizes that it has not received an acknowledgement from the device.Said control logic generates a second notification of output data andoutput data, addressed to the same USB function. Said notification andoutput data are transmitted to the LEX subsystem as OUT/DATAX packets.On receipt of said OUT/DATAX packets, the control logic (266) within theLEX subsystem recognizes that it has a Result packet stored in memoryfrom the same function identified by the further OUT/DATAX packets. Saidcontrol logic retrieves said stored Result packet from memory andtransmits the same to the Host. Said further OUT/DATAX packets aretransmitted to the device in the same manner as the previous OUT/DATAXpackets. The information is then received by the control logic (269)within the device.

[0315] On receipt of the OUT/DATAX packets, the control logic (269)within the device generates an acknowledgement and transmits the same asa Result packet to the REX-Hub. Said Result packet is then transmittedto and stored in the LEX subsystem in the same manner as the previousResult packet.

[0316] The above-described process is repeated for subsequentnotifications of output data and output data from the Host by thedistributed control logic (e.g. 265, 266, 267, 268, 269).

[0317]FIG. 23 provides a sequence diagram showing a high bandwidthinterrupt input transfer, between a high-speed host and a high-speeddevice, according to the invention. In Microframe Y₀, the control logic(280) within the Host generates a request for input data, addressed to aparticular USB function. Said request is transmitted to the LEXsubsystem as an IN packet. On receipt of said IN packet, the controllogic (281) within the LEX subsystem recognizes the lack of data thatcorresponds to the input request in its buffer memory. Said controllogic (281) then generates a synthetic data packet and transmits thesame as a NULL packet to the Host. Said synthetic data packet is a datapacket containing a zero length data payload and is used to satisfy thetiming requirements of the USB protocol while causing no disturbance tothe actual information being carried by the protocol. The control logic(281) within the LEX subsystem forwards the IN packet to the REX-FPGAsubsystem. The control logic (282) within the REX-FPGA subsystemforwards said IN packet to the REX-Hub. The control logic (283) withinthe REX-Hub forwards said request for input data as an IN packet to theDevice. The control logic (284) within the device assembles therequested interrupt data and transmits the same as a Result packet tothe REX-Hub. The control logic (283) within the REX-Hub forwards theResult packet to the REX-FPGA subsystem. On receipt of said Resultpacket, the control logic (282) within the REX-FPGA subsystem generatesa synthetic acknowledgement packet that is transmitted as an ACK packetto the REX-Hub. The control logic (283) within the REX-Hub forwards saidACK packet to the Device. The control logic (282) within the REX-FPGAsubsystem forwards said Result packet to the LEX subsystem and thecontrol logic (281) within the LEX subsystem stores said result packetin its buffer memory.

[0318] In the same microframe, Microframe Y₀, the control logic (280)within the Host generates a second request for input data, addressed tothe same USB function. Said request is transmitted to the LEX subsystemas an IN packet. On receipt of said IN packet, the control logic (281)within the LEX subsystem recognizes the lack of data that corresponds tothe input request in its buffer memory. Said control logic (281) thengenerates a synthetic data packet and transmits the same as a NULLpacket to the Host. The second IN packet is then transmitted to theDevice in the same manner as the previous IN packet.

[0319] On receipt of the second request for input data, the controllogic (284) within the device assembles the requested interrupt data andtransmits the same as a second Result packet to the REX-Hub. The controllogic (283) within the REX-Hub forwards said Result packet to theREX-FPGA subsystem. On receipt of said Result packet, the control logic(282) within the REX-FPGA subsystem generates a syntheticacknowledgement packet that is transmitted as an ACK packet to theREX-Hub. The control logic (283) within the REX-Hub forwards said ACKpacket to the device. The control logic (282) within the REX-FPGAsubsystem forwards said Result packet to the LEX subsystem and thecontrol logic (281) within the LEX subsystem stores said result packetin its buffer memory.

[0320] In the same microframe, Microframe Y₀, the control logic (280)within the Host generates a third request for input data, addressed tothe same USB function. Said request is transmitted to the LEX subsystemas an IN packet. On receipt of said IN packet, the control logic (281)within the LEX subsystem recognizes the lack of data that corresponds tothe input request in its buffer memory. Said control logic (281) thengenerates a synthetic negative acknowledgement packet and transmits thesame as a NAK packet to the Host. Said NAK packet warns the Host that itwill not receive a response to its request and enables said Host toprogress to the next transaction. The third IN packet is thentransmitted to the Device in the same manner as the first and second INpackets.

[0321] On receipt of the third request for input data, the control logic(284) within the device assembles the requested interrupt data andtransmits the same as a third Result packet to the REX-Hub. The controllogic (283) within the REX-Hub forwards said Result packet to theREX-FPGA subsystem. On receipt of said Result packet, the control logic(282) within the REX-FPGA subsystem generates a syntheticacknowledgement packet that is transmitted as an ACK packet to theREX-Hub. The control logic (283) within the REX-Hub forwards said ACKpacket to the device. The control logic (282) within the REX-FPGAsubsystem forwards said Result packet to the LEX subsystem and thecontrol logic (281) within the LEX subsystem stores said Result packetin its buffer memory.

[0322] In the next microframe, Microframe Y₁, the control logic (285)within the Host recognizes that it has not received the requested dataand automatically retries the transaction by generating a furtherrequest addressed to the same USB function as in Microframe Y₀. Saidfurther request is transmitted to the LEX subsystem as an IN packet. Onreceipt of said IN packet, the control logic (286) within the LEXsubsystem recognizes that it has a Result packet stored in memory fromthe same function identified by the further IN packet Said control logicretrieves said stored Result packet from memory and transmits the samepacket to the Host. When the control logic (285) of the Host receivesthe requested Result packet from the LEX, said control logic generatesan ACK packet to acknowledge a successful transmission. Upon receipt ofthe ACK packet from the host, the control logic (286) within the LEXsubsystem absorbs said packet Said control logic (286) forwards thefurther IN packet to the REX-FPGA subsystem. The control logic (287)within the REX-FPGA forwards said IN packet to the REX-Hub. The controllogic (288) within the REX-Hub forwards said request for input data asan IN packet to the Device.

[0323] On receipt of the request for input data, the control logic (289)within the device assembles the requested interrupt data and transmitsthe same as a Result packet to the REX-Hub. The control logic (288)within the REX-Hub forwards said Result packet to the REX-FPGAsubsystem. On receipt of said Result packet, the control logic (287)within the REX-FPGA subsystem generates a synthetic acknowledgementpacket that is transmitted as an ACK packet to the REX-Hub. The controllogic (288) within the REX-Hub forwards said ACK packet to the device.The control logic (287) within the REX-FPGA subsystem forwards saidResult packet to the LEX subsystem and the control logic (286) withinthe LEX subsystem stores said Result packet in its buffer memory.

[0324] Within the same microframe, Microframe Y₁, the control logic(285) within the Host generates a second request for input data. Saidrequest is transmitted to the LEX subsystem as an IN packet. The controllogic (286) within the LEX subsystem retrieves the second stored Resultpacket from the previous microframe and transmits the same packet to theHost. When the control logic (285) of the Host receives the requestedResult packet from the LEX, said control logic generates an ACK packetto acknowledge a successful transmission. Upon receipt of the ACK packetfrom the host, the control logic (286) within the LEX subsystem absorbssaid packet. Said second IN packet is forwarded to the device in thesame manner as previous IN packets.

[0325] On receipt of the second request for input data, the controllogic (289) within the device assembles the requested interrupt data andtransmits the same as a Result packet. Said Result packet is transmittedto and stored in the LEX subsystem in the same manner as previous Resultpackets. On receipt of said result packet, the control logic (287)within the REX-FPGA subsystem generates a synthetic acknowledgementpacket that is transmitted as an ACK packet to the device in the samemanner as previous synthetic ACK packets.

[0326] Within the same microframe, Microframe Y₁, the control logic(285) within the host generates a third request for input data. Saidrequest is transmitted to the LEX subsystem as an IN packet. The controllogic (286) within the LEX subsystem retrieves the third stored Resultpacket from the previous microframe and transmits the same packet to theHost. When the control logic (285) of the Host receives the requestedResult packet from the LEX, said control logic generates an ACK packetto acknowledge a successful transmission. Upon receipt of the ACK packetfrom the host, the control logic (286) within the LEX subsystem absorbssaid packet. Said third IN packet is forwarded to the device in the samemanner as previous IN packets.

[0327] On receipt of the third request for input data, the control logic(289) within the device assembles the requested interrupt data andtransmits the same a Result packet. Said Result packet is transmitted toand stored in the LEX subsystem in the same manner as previous Resultpackets. On receipt of said result packet, the control logic (287)within the REX-FPGA subsystem generates a synthetic acknowledgementpacket that is transmitted as an ACK packet to the device in the samemanner as previous synthetic ACK packets.

[0328] The above-described process is repeated for subsequent input datarequests from the Host by the distributed control logic (e.g. 285, 286,287, 288 & 289).

[0329]FIG. 24 provides a sequence diagram showing a high bandwidthinterrupt output transfer, between a high-speed host and a high-speeddevice. In Microframe Y₀, the control logic (280) within the Hostgenerates a notification of output data followed by output data,addressed to a particular USB function. Said notification of output dataand output data are transmitted to the LEX subsystem as an OUT packetand a DATAX packet (OUT/DATAX packets). Said DATAX packet representseither a DATA0 packet or DATA1 packet. On receipt of said OUT/DATAXpackets, the control logic (281) within the LEX subsystem generates asynthetic acknowledgement packet and transmits the same as an ACK packetto the Host. Said synthetic acknowledgement packet tells the host thatthe data transmission is successful and enables said host to progress tothe next transaction. The control logic (281) within the LEX subsystemforwards the OUT/DATAX packets to the REX-FPGA subsystem. The controllogic (282) within the REX-FPGA subsystem forwards said OUT/DATAXpackets to the REX-Hub. The control logic (283) within the REX-Hubforwards said OUT/DATAX packets to the Device.

[0330] The control logic (284) within the device generates a Resultpacket corresponding to the OUT/DATAX packets and transmits the same tothe REX-Hub. The control logic (283) within the REX-Hub forwards saidResult packet to the REX-FPGA subsystem. The control logic (282) withinthe REX-FPGA subsystem forwards said Result packet to the LEX subsystemand the control logic (281) within the LEX subsystem stores said Resultpacket in its buffer memory.

[0331] In the same microframe, Microframe Y₀, the control logic (280)within the Host generates a second notification of output data andoutput data, addressed to the same USB function. Said notification andoutput data are transmitted to the LEX subsystem as OUT/DATAX packets.On receipt of said OUT/DATAX packets, the control logic (281) within theLEX subsystem generates a synthetic acknowledgement packet and transmitsthe same as an ACK packet to the Host. The second OUT/DATAX packets arethen transmitted to the Device in the same manner as the previousOUT/DATAX packets. On receipt of the second notification of output dataand output data, the control logic (284) within the device generates asecond Result packet and transmits the same to the REX-Hub. The controllogic (283) within the REX-Hub forwards said Result packet to theREX-FPGA subsystem. The control logic (282) within the REX-FPGAsubsystem forwards said Result packet to the LEX subsystem and thecontrol logic (281) within the LEX subsystem stores said result packetin its buffer memory.

[0332] In the same microframe, Microframe Y₀, the control logic (280)within the Host generates a third notification of output data and outputdata, addressed to the same USB function. Said notification and outputdata are transmitted to the LEX subsystem as OUT/DATAX packets. Onreceipt of said OUT/DATAX packets, the control logic (281) within theLEX subsystem generates a synthetic negative acknowledgement packet andtransmits the same as an NAK packet to the Host. Said NAK packet warnsthe Host that it will not receive a data transmission status to thenotification of output data and enables said Host to progress to thenext transaction. The third OUT/DATAX packets are then transmitted tothe Device in the same manner as the first two OUT/DATAX packets.

[0333] On receipt of the third notification of output data and outputdata, the control logic (284) within the device generates a third Resultpacket and transmits the same to the REX-Hub. The control logic (283)within the REX-Hub forwards said Result packet to the REX-FPGAsubsystem. The control logic (282) within the REX-FPGA subsystemforwards said Result packet to the LEX subsystem and the control logic(281) within the LEX subsystem stores said result packet in its buffermemory.

[0334] In Microframe Y₁, the control logic (285) within the Hostgenerates a notification of output data followed by output data,addressed to the same USB function. Said notification and output dataare transmitted to the LEX subsystem as OUT/DATAX packets. On receipt ofsaid OUT/DATAX packets, the control logic (286) within the LEX subsystemrecognizes that it has a Result packet stored in memory from the samefunction identified by the further OUT/DATAX packets. Said control logicretrieves said stored Result packet from memory and transmits the sameto the Host. Said further OUT/DATAX packets are transmitted to thedevice in the same manner as the previous OUT/DATAX packets. Theinformation is received by the control logic (289) within the device.

[0335] On receipt of the OUT/DATAX packets, the control logic (289)within the device generates a Result packet and transmits the same tothe REX-Hub. Said Result packet is then transmitted to and stored in theLEX subsystem in the same manner as the previous Result packets.

[0336] In the same microframe, Microframe Y₁, the control logic (285)within the Host generates a second notification of output data andoutput data, addressed to the same USB function. Said notification andoutput data are transmitted to the LEX subsystem as OUT/DATAX packets.On receipt of said OUT/DATAX packets, the control logic (286) within theLEX subsystem recognizes that it has a Result packet stored in memoryfrom the same function identified by the further OUT/DATAX packets. Saidcontrol logic retrieves said stored Result packet from memory andtransmits the same as a Result packet to the Host. Said furtherOUT/DATAX packets are transmitted to the device in the same manner asthe previous OUT/DATAX packets. The information is received by thecontrol logic (289) within the device.

[0337] On receipt of the OUT/DATAX packets, the control logic (289)within the device generates a Result packet and transmits the same tothe REX-Hub. Said Result packet is then transmitted to and stored in theLEX subsystem in the same manner as the previous Result packets.

[0338] In the same microframe, Microframe Y₁, the control logic (285)within the Host generates a third notification of output data and outputdata, addressed to the same USB function. Said notification and outputdata are transmitted to the LEX subsystem as OUT/DATAX packets. Onreceipt of said OUT/DATAX packets, the control logic (286) within theLEX subsystem recognizes that it has a Result packet stored in memoryfrom the same function identified by the further OUT/DATAX packets. Saidcontrol logic retrieves said stored Result packet from memory andtransmits the same as a Result packet to the Host. Said furtherOUT/DATAX packets are transmitted to the device in the same manner asthe previous OUT/DATAX packets. The information is received by thecontrol logic (289) within the device.

[0339] On receipt of the OUT/DATAX packets, the control logic (289)within the device generates a Result packet and transmits the same tothe REX-Hub. Said Result packet is then transmitted to and stored in theLEX subsystem in the same manner as the previous Result packets.

[0340] The above-described process is repeated for subsequentnotifications of output data and output data from the Host by thedistributed control logic (e.g. 285, 286, 287, 288, & 289).

[0341]FIG. 25 provides a simplified timing diagram showing control andbulk data transfers, which are two special cases of asynchronoustransfers, according to the USB protocol. The diagram is constructedfrom the point of view of a USB Host Controller, normally included on aPC motherboard (Host PC). For a full-speed host, the USB protocoldivides time allocation on the shared bus into regular Frames, each of 1ms in duration. For a high-speed host, time allocation on the shared busis divided into regular Microframes, each of 125 _(μ)s in duration. Thestart of each microframe is identified in the diagram as I1, I2, . . . ,I_(n), . . . , I_(n+k), etc., where n and k are positive integers.

[0342] When a Host Controller is engaged upon a control or bulk datatransfer with a device, the Host Controller issues requests for datatransfer to said device on an as needed basis. These requests areidentified in FIG. 25 as packets, R1 & R2 (10 & 13). Under the USBprotocol, a USB device must respond to the request from a full speedhost within 16 full-speed bit-times. In response to requests from ahigh-speed host, a USB device must respond within 736 high-speedbit-times. Control and bulk devices are not required to respond to arequest within the same microframe where said request is generated.However, control and bulk devices must respond within the same framewhere a request is generated because control and bulk transactions arenot allowed to span a frame boundary. The responses generated by thedevice are shown in the diagram as packets A1 & A2 (11 & 14). On receiptof a response packet, the Host Controller also emits an acknowledgementand these acknowledgements are identified as packets K1 & K2 (12 & 15).It is commonly expected that transfer A1 (11) will be delivered inresponse to request R1 (10) and acknowledgement K1 (12) will be emittedon receipt of R1 (10) within the same frame, transfer A2 (14) will bedelivered in response to request R2 (13) and acknowledgement K2 (15)will be emitted on receipt of R2 (13) within the same frame, and so onuntil the requests are terminated. For control and bulk transfers, datarequests are not generated periodically and transfers can take placeanytime when the shared bus has unoccupied bandwidth. Request R2 (13)may be generated immediately after acknowledgement K1 (12) is receivedor said request may be generated several microframes after K1 (12) isreceived. The time elapsed between K1 (12) and R2 (13) depends on thebandwidth availability on the shared bus at that particular time and thesame is true for subsequent requests. The time span within which atransaction takes place is not fixed and is identified by “Time” in FIG.25.

[0343]FIG. 26 provides a simplified timing diagram showing control andbulk data transfers, two special cases of asynchronous transfers,according to the present invention. The diagram shows the progression ofpackets through the various subsystems comprising the invention.Timelines are presented for the Host PC (1), Local Expander (4) andRemote Expander FPGA (8) subsystems. Each transaction may take place inthe span of one or more microframes but must be completed before thearrival of the subsequent frame boundary. The elapsed time betweenconsecutive requests is not fixed and may be less than one microframe,one microframe, or more than one microframe. The time span within whicheach transaction takes place is identified by “Time” in FIG. 26.

[0344] An asynchronous transfer is initiated from a Host PC by emittinga request for input data R1 (20) to a particular USB address andend-point. Said request R1 (20) is received by the LEX and retransmittedas R1 (25) over the external cabling to the REX-FPGA. Said retransmittedpacket R1 (25) is received by the REX-FGPA and forwarded as R1 (31) tothe REX-Hub. A synthetic negative acknowledgement packet is generated bythe LEX and transmitted as N1 (26) to the host.

[0345] The target device generates an input data packet A1 (32).According to the USB protocol for low-speed and full-speed isochronoustransfers, a device with a detachable cable must generate a responsewithin 6.5 full-speed bit-times of the end of the corresponding request.For high-speed isochronous transfers, a device must generate a responsewithin 192 high-speed bit times. Said input data packet A1 (32) isreceived by the REX-Hub and the REX-FPGA subsystem and retransmitted asA1 (27) over the external wiring to the LEX. Said retransmitted responseA1 (27) is not immediately forwarded to the Host PC, but is storedwithin the memory of the LEX subsystem. A synthetic acknowledgementpacket K1 (33) is generated by the REX-FGPA subsystem and transmitted asK1 (33) to the REX-Hub.

[0346] The Host PC (1) notices that it did not receive data in responseto its request R1 (20), and retries the transaction by generating afurther request R2 (22) to the same USB address and end-point. Uponreceiving request R2 (28), the LEX subsystem retrieves response A1 (27)from its memory buffers and forwards it to the Host PC as response A1(29). Said response is received by the Host as response A1 (23) and saidrequest R2 (28) is absorbed by the LEX subsystem. Upon receiving saidresponse A1 (23), the Host generates an acknowledgement packet andtransmits the packet as packet K1 (24) to the LEX subsystem. Saidacknowledgement packet K1 (30) is received and absorbed by LEX.

[0347] The above-described protocol sequence is repeated for eachinitial input data request generated by the Host Controller.

[0348]FIG. 27 is a sequence diagram showing a control input transfer,between a high-speed host and a low-speed device. In the Set-up Phase,the control logic (340) within the Host generates a startsplit-transaction, a notification of device set-up, and a data packetaddressed to a particular USB function. Said split-transaction,notification, and data are transmitted to the LEX subsystem as a SSPLITpacket, a SETUP packet, and a DATA0 packet, respectively. On receipt ofsaid SSPLIT/SETUP/DATA0 packets, the control logic (341) within the LEXsubsystem recognizes it has not yet received an acknowledgement from thedevice so said control logic generates a synthetic negativeacknowledgement and transmits the same to the host as a NAK packet. Thecontrol logic (341) within the LEX subsystem forwards saidSSPLIT/SETUP/DATA0 packets to the REX-FPGA subsystem. The control logic(342) within the REX-FPGA subsystem forwards said SSPLIT/SETUP/DATA0packets to the REX-Hub. On receipt of said SSPLIT/SETUP/DATA0 packets,the control logic (343) within the REX-Hub generates an acknowledgementand transmits the same as an ACK packet to the REX-FPGA subsystem. Thecontrol logic (342) within the REX-FPGA subsystem forwards said ACKpacket to the LEX subsystem and the control logic (341) within the LEXsubsystem stores said ACK packet in its buffer memory. The control logic(343) within the REX-Hub absorbs said SSPLIT packet and forwards saidSETUP/DATA0 packets to the Device.

[0349] Upon successful receipt of the SETUP/DATA0 packets, the controllogic (344) within the device generates an acknowledgement and transmitsthe same as a Result packet to the REX-Hub. The control logic (343)within the REX-Hub stores said Result packet in its buffer memory.

[0350] At a later time, the control logic (340) within the hostrecognizes that it has not received an acknowledgement from the deviceand automatically retries the transaction by issuing furtherSSPLIT/SETUP/DATA0 packets addressed to the same USB function. Onreceipt of said SSPLIT/SETUP/DATA0 packets, the control logic (341)within the LEX subsystem recognizes that it has a Result packet storedin memory from the same function identified by the furtherSSPLIT/SETUP/DATA0 packets. Said control logic retrieves said storedResult packet from memory and transmits the same packet to the Host.Said control logic (341) also recognizes that said SSPLIT/SETUP/DATA0packets are merely a repetition of the previous SSPLIT/SETUP/DATA0packets and absorbs said packets.

[0351] At a later time, the control logic (340) within the hostgenerates a complete split-transaction and a notification of deviceset-up. Said complete split-transaction and notification of deviceset-up are transmitted to the LEX subsystem as a CSPLIT packet and aSETUP packet (CSPLIT/SETUP packets). On receipt of the CSPLIT/SETUPpackets, the control logic (341) within the LEX subsystem recognizesthat it has not received an acknowledgement from the device so saidcontrol logic (341) generates a NYET packet and transmits the same tothe host. Said NYET packet warns the host that the LEX subsystem has notyet received a response from the device and enables said host toprogress to the next transaction. Said control logic (341) forwards saidCSPLIT/SETUP packets to the REX-FPGA subsystem. The control logic (342)within the REX-FPGA subsystem forwards said CSPLIT/SETUP packets to theREX-Hub.

[0352] On receipt of the CSPLIT/SETUP packets, the control logic (343)within the REX-Hub recognizes that it has an acknowledgement packetstored in memory. Said control logic retrieves said storedacknowledgement packet from memory and transmits the same packet as aResult packet to the REX-FPGA subsystem. The control logic (342) withinthe REX-FPGA subsystem forwards said Result packet to the LEX subsystem.The control logic (341) within the LEX subsystem stores said Resultpacket in Its buffer memory.

[0353] At a later time, the control logic (340) within the hostrecognizes that it has not received an acknowledgement from the deviceand automatically retries the transaction by issuing a further completesplit-transaction and a notification of device set-up, addressed to thesame USB function. Said complete split-transaction and notification ofdevice set-up are transmitted to the LEX subsystem as furtherCSPLIT/SETUP packets. On receipt of said further CSPLIT/SETUP packets,the control logic (341) within the LEX subsystem recognizes that it hasan acknowledgement packet stored in memory from the same functionidentified by the further CSPLIT/SETUP packets. Said control logicretrieves said stored acknowledgement packet from memory and transmitsthe same as a Result packet to the Host Said control logic (341) alsorecognizes that said CSPLIT/SETUP packets are merely a repetition of theprevious CSPLIT/SETUP packets and absorbs said packets.

[0354] In the Data Phase, the control logic (345) within the hostgenerates a start split-transaction and a request for input dataaddressed to the same USB function as the Set-up Phase. Said startsplit-transaction and request for input data are transmitted to the LEXsubsystem as a SSPLIT packet and an IN packet (SSPLIT/IN packets). Onreceipt of the SSPLIT/IN packets, the control logic (346) within the LEXsubsystem recognizes that it has not received an acknowledgement fromthe device so said control logic generates a synthetic negativeacknowledgement and transmits the same to the host as a NAK packet. Saidcontrol logic (346) forwards said SSPLIT/IN packets to the REX-FPGAsubsystem. The control logic (347) within the REX-FPGA subsystemforwards said SSPLIT/IN packets to the REX-Hub.

[0355] On receipt of the SSPLIT/IN packets, the control logic (348)within the REX-Hub generates an acknowledgement packet and transmits thesame to the REX-FPGA subsystem as a Result packet. The control logic(347) within the REX-FPGA subsystem forwards said Result packet to theLEX subsystem and the control logic (346) within the LEX subsystemstores said Result packet in its buffer memory. The control logic (348)within the REX-Hub forwards the request for input data as an IN packetto the device. On receipt of said IN packet, the control logic (349)within the device assembles the requested data and transmits the same asa Result packet to the REX-Hub. The control logic (348) within theREX-Hub stores said Result packet in its buffer memory. On receipt ofthe Result packet, said control logic (348) generates an ACK packet toacknowledge a successful transmission.

[0356] At a later time, the control logic (345) within the hostrecognizes that it has not received the requested data from the deviceand automatically retries the transaction by issuing a further startsplit-transaction and a request for input data addressed to the same USBfunction. Said start split-transaction and request for input data aretransmitted as a SSPLIT/IN packets to the LEX subsystem. On receipt ofthe SSPLIT/IN packets, the control logic (346) within the LEX subsystemrecognizes that it has an acknowledgement packet stored in memory fromthe same function identified by the further SSPLIT/IN packets. Saidcontrol logic retrieves the stored acknowledgement packet from memoryand transmits the same as a Result packet to the Host. Said controllogic (346) also recognizes that said SSPLIT/IN packets are merely arepetition of the previous SSPLIT/IN packets and absorbs said packets.

[0357] At a yet later time, the control logic (345) within the hostgenerates a complete split-transaction and a request for input data,addressed to the same USB function. Said complete split-transaction andrequest for input data are transmitted to the LEX subsystem as a CSPLITpacket said OUT/DATA1 packets, the control logic (354) within the devicegenerates an acknowledgement and transmits the same as a Result packetto the REX-Hub. The control logic (353) within the REX-Hub stores saidResult packet in its buffer memory.

[0358] At a later time, the control logic (350) within the hostrecognizes that it has not received an acknowledgement from the deviceand automatically retries the transaction by issuing furtherSSPLIT/OUT/DATA1 packets to the LEX subsystem. On receipt of theSSPLIT/OUT/DATA1 packets, the control logic (351) within the LEXsubsystem recognizes that it has an acknowledgement packet stored inmemory from the same function identified by the further SSPLIT/OUT/DATA1packets. Said control logic retrieves the stored acknowledgement packetfrom memory and transmits the same as a Result packet to the Host. Saidcontrol logic (351) also recognizes that said SSPLIT/OUT/DATA1 packetsare merely a repetition of the previous SSPLIT/OUT/DATA1 packets andabsorbs said packets.

[0359] At a yet later time, the control logic (350) within the hostgenerates a complete split-transaction and a notification of outputdata, addressed to the same USB function. Said completesplit-transaction and notification of output data are transmitted asCSPLIT/OUT packets to the LEX subsystem. On receipt of the CSPLIT/OUTpackets, the control logic (351) within the LEX subsystem recognizesthat it has not received an acknowledgement packet from the device sosaid control logic generates a synthetic NYET packet and transmits thesame to the host. Said NYET packet informs the host that the LEXsubsystem has not yet received a response from the device and enablessaid host to progress to the next transaction. The control logic (351)within the LEX subsystem forwards said CSPLIT/OUT packets to theREX-FPGA subsystem. The control logic (352) within the REX-FPGAsubsystem forwards said CSPLIT/OUT packets to the REX-Hub.

[0360] On receipt of the CSPLIT/OUT packets, the control logic (353)within the REX-Hub recognizes that it has in its buffer memory a Resultpacket that corresponds to the further CSPLIT/OUT packets. Said controllogic (353) retrieves said stored Result packet and transmits the sameto the REX-FPGA subsystem. The control logic (352) within the REX-FPGAsubsystem forwards said Result packet to the LEX subsystem and thecontrol logic (351) within the LEX subsystem stores said Result packetin its buffer memory.

[0361] At a later time, the control logic (350) within the hostrecognizes that it has not received an acknowledgement from the deviceand automatically retries the transaction by issuing further CSPLIT/OUTpackets to the LEX subsystem. On receipt of the CSPLIT/OUT packets, thecontrol logic (351) within the LEX subsystem recognizes that it has anacknowledgement packet stored in memory from the same functionIdentified by the further CSPLIT/OUT packets. Said control logicretrieves said stored packet from memory and transmits the same as aResult packet to the Host. Said control logic (351) also recognizes thatsaid CSPLIT/OUT packets are merely a repetition of the previousCSPLIT/OUT packets and absorbs said packets.

[0362] According to the invention, the protocol handling for control INtransfers between a high-speed host and a full-speed device is the sameas the protocol handling for control IN transfers between a high-speedhost and a low-speed device, as described in FIG. 27 by control logics(340) to (354).

[0363]FIG. 28 is a sequence diagram showing a control output transfer,between a high-speed host and a low-speed device. In the Set-up Phase,the control logic (340) within the Host generates startsplit-transaction, a notification of device set-up, and a data packetaddressed to a particular USB function. Said split-transaction,notification, and data are transmitted to the LEX subsystem asSSPLIT/SETUP/DATA0 packets. On receipt of the SSPLIT/SETUP/DATA0packets, the control logic (341) within the LEX subsystem recognizes thelack of Result that corresponds to the notification of device set-up inits memory so said control logic generates a synthetic negativeacknowledgement and transmits the same to the host as a NAK packet. Thecontrol logic (341) within the LEX subsystem forwards saidSSPLIT/SETUP/DATA0 packets to the REX-FPGA subsystem. The control logic(342) within the REX-FPGA subsystem forwards said SSPLIT/SETUP/DATA0packets to the REX-Hub. On receipt of said SSPLIT/SETUP/DATA0 packets,the control logic (343) within the REX-Hub generates an acknowledgementand transmits the same as an ACK packet to the REX-FPGA subsystem. Thecontrol logic (342) within the REX-FPGA subsystem forwards said ACKpacket to the LEX subsystem and the control logic (341) within the LEXsubsystem stores said ACK packet in its buffer memory. The control logic(343) within the REX-Hub forwards said SETUP/DATA0 packets to theDevice.

[0364] On receipt of the SETUP/DATA0 packets, the control logic (344)within the device assembles the requested Result and transmits the sameas a Result packet to the REX-Hub. The control logic (343) within theREX-Hub stores said Result packet in its buffer memory.

[0365] At a later time, the control logic (340) within the hostrecognizes that it has not received an acknowledgement from the deviceand automatically retries the transaction by issuing furtherSSPLIT/SETUP/DATA0 packets to the LEX subsystem. On receipt of theSSPLIT/SETUP/DATA0 packets, the control logic (341) within the LEXsubsystem recognizes that it has an acknowledgement packet stored inmemory from the same function identified by the furtherSSPLIT/SETUP/DATA0 packets. Said control logic retrieves said storedacknowledgement packet from memory and transmits the same as a Resultpacket to the Host. Said control logic (341) also recognizes that saidSSPLIT/SETUP/DATA0 packets are a repetition of the previousSSPLIT/SETUP/DATA0 packets and absorbs said packets.

[0366] At a later time, the control logic (340) within the hostgenerates a complete split-transaction and a notification of deviceset-up. Said complete split-transaction and notification of deviceset-up are transmitted to the LEX subsystem as a CSPLIT packet and aSETUP packet (CSPLIT/SETUP packets). On receipt of the CSPLIT/SETUPpackets, the control logic (341) within the LEX subsystem recognizes thelack of Result that corresponds to the notification of data set-up inits memory so said control logic (341) generates a NYET packet andtransmits the same to the host. Said NYET packet warns the host that theLEX subsystem has not yet received a response from the device andenables said host to progress to the next transaction. Said controllogic (341) forwards said CSPLIT/SETUP packets to the REX-FPGAsubsystem. The control logic (342) within the REX-FPGA subsystemforwards said CSPLIT/SETUP packets to the REX-Hub.

[0367] On receipt of the CSPLIT/SETUP packets, the control logic (343)within the REX-Hub recognizes that it has a Result packet stored inmemory. Said control logic retrieves said stored Result packet frommemory and transmits the same packet as a Result packet to the REX-FPGAsubsystem. The control logic (342) within the REX-FPGA subsystemforwards said Result packet to the LEX subsystem. The control logic(341) within the LEX subsystem stores said Result packet in its buffermemory.

[0368] At a later time, the control logic (340) within the hostrecognizes that it has not received a Result from the device andautomatically retries the transaction by Issuing further CSPLIT/SETUPpackets to the LEX subsystem. On receipt of the further CSPLIT/SETUPpackets, the control logic (341) within the LEX subsystem recognizesthat it has a Result packet stored in memory from the same functionidentified by the further CSPLIT/SETUP packet. Said control logic (341)retrieves said stored Result packet from memory and transmits the samepacket to the Host.

[0369] In the Data Phase, the control logic (345) within the hostgenerates a start split-transaction, a notification of output data, anda data packet, addressed to the same USB function as the Set-up Phase.Said start split-transaction, notification of output data, and datapacket are transmitted to the LEX subsystem as a SSPLIT packet, an OUTpacket, and a DATA1 packet, respectively (SSPLIT/OUT/DATA1 packets). Onreceipt of the SSPLIT/OUT/DATA1 packets, the control logic (346) withinthe LEX subsystem recognizes the lack of Result that corresponds to theinput request in its buffer memory so said control logic generates asynthetic negative acknowledgement and transmits the same to the host asa NAK packet. Said control logic (346) forwards said SSPLIT/OUT/DATA1packets to the REX-FPGA subsystem. The control logic (347) within theREX-FPGA subsystem forwards said SSPLIT/OUT/DATA1 packets to theREX-Hub.

[0370] On receipt of the SSPLIT/OUT/DATA1 packets, the control logic(348) within the REX-Hub generates an acknowledgement packet andtransmits the same to the REX-FPGA subsystem as a Result packet. Thecontrol logic (347) within the REX-FPGA subsystem forwards said Resultpacket to the LEX subsystem and the control logic (346) within the LEXsubsystem stores said Result packet in its buffer memory. The controllogic (348) within the REX-Hub absorbs said SSPLIT packet and forwardssaid OUT/DATA1 packets to the device. On receipt of said OUT/DATA1packets, the control logic (349) within the device assembles therequested Result and transmits the same as a Result packet to theREX-Hub. The control logic (348) within the REX-Hub stores said Resultpacket in its buffer memory.

[0371] At a later time, the control logic (345) within the hostrecognizes that it has not received the requested Result andautomatically retries the transaction by issuing furtherSSPLIT/OUT/DATA1 packets to the LEX subsystem. On receipt of theSSPLIT/OUT/DATA1 packets, the control logic (346) within the LEXsubsystem recognizes that it has a Result packet stored in memory fromthe same function identified by the further SSPLIT/OUT/DATA1 packets.Said control logic retrieves said stored Result packet from memory andtransmits the same packet to the Host Said control logic (346) alsorecognizes that said SSPLIT/OUT/DATA1 packets are a repetition of theprevious SSPLIT/OUT/DATA1 packets and absorbs said packets.

[0372] At a yet later time, the control logic (345) within the hostgenerates a complete split-transaction and a notification of outputdata. Said complete split-transaction and notification of output dataare transmitted to the LEX subsystem as a CSPLIT packet and an OUTpacket (CSPLIT/OUT packets). On receipt of the CSPLIT/OUT packets, thecontrol logic (346) within the LEX subsystem recognizes the lack ofResult that corresponds to the notification of output data in its memoryso said control logic (346) generates a NYET packet and transmits thesame to the host. Said NYET packet warns the host that the LEX subsystemhas not yet received a response from the device and enables said host toprogress to the next transaction. Said control logic (346) forwards saidCSPLIT/SETUP packets to the REX-FPGA subsystem. The control logic (347)within the REX-FPGA subsystem forwards said CSPLIT/OUT packets to theREX-Hub.

[0373] On receipt of the CSPLIT/OUT packets, the control logic (348)within the REX-Hub recognizes that it has a Result packet stored inmemory from the same function identified by the CSPLIT/OUT packets. Saidcontrol logic retrieves said stored Result packet from memory andtransmits the same packet to the REX-FPGA subsystem. The control logic(347) within the REX-FPGA subsystem forwards said Result packet to theLEX subsystem and the control logic (346) within the LEX subsystemstores said Result packet in its buffer memory.

[0374] At a later time, the control logic (345) within the hostrecognizes that it has not received the requested Result andautomatically retries the transaction by issuing a further CSPLIT packetand a further OUT packet to the LEX subsystem. On receipt of theCSPLIT/OUT packets, the control logic (346) within the LEX subsystemrecognizes that it has a Result packet stored in memory from the samefunction identified by the further CSPLIT/OUT packets. Said controllogic retrieves said stored Result packet from memory and transmits thesame packet to the Host. Said control logic (346) also recognizes thatsaid CSPLIT/OUT packets are a repetition of the previous CSPLIT/OUTpackets and absorbs said packets.

[0375] In the Status Phase, the control logic (350) within the hostgenerates a start split-transaction and a request for input data,addressed to the same USB function as the Data Phase. Said startsplit-transaction and request for input data are transmitted to the LEXsubsystem as a SSPLIT packet and an IN packet (SSPLIT/IN packets). Onreceipt of said SSPLIT/IN packets, the control logic (351) within theLEX subsystem recognizes that the lack of Result in its memory so itgenerates a synthetic negative acknowledgement and transmits the same asa NAK packet to the host. Said control logic forwards the SSPLIT/INpackets to the REX-FPGA subsystem. The control logic (352) within theREX-FPGA subsystem forwards said SSPLIT/IN packets to the REX-Hub. Onreceipt of the SSPLIT/IN packets, the control logic (353) within theREX-Hub generates a Result and transmits the same as a Result packet tothe REX-FPGA subsystem. The control logic (352) within the REX-FGPAsubsystem forwards said Result packet to the LEX subsystem and thecontrol logic (351) within the LEX subsystem stores said Result packetin its buffer memory. The control logic (353) within the REX-Hub absorbssaid SSPLIT packet and forwards said IN packet to the device.

[0376] On receipt of the IN packet, the control logic (354) within thedevice assembles the requested data and transmits the same as a Resultpacket to the REX-Hub. Upon receipt of the Result packet, the controllogic (353) within the REX-Hub generates an ACK packet to acknowledge asuccessful transmission and transmits the same to the device.

[0377] At a later time, the control logic (350) within the hostrecognizes that it has not received an acknowledgement from the deviceand automatically retries the transaction by issuing a further SSPLITpacket and a further IN packet to the LEX subsystem. On receipt of thefurther SSPLIT/IN packets, the control logic (351) within the LEXsubsystem recognizes that it has an acknowledgement packet stored inmemory from the same function identified by the further SSPLIT/INpackets. Said control logic retrieves said stored acknowledgement packetfrom memory and transmits the same as a Result packet to the Host. Saidcontrol logic also recognizes that said SSPLIT/IN packets are arepetition of the previous SSPLIT/IN packets and absorbs said packets.

[0378] At a yet later time, the control logic (350) within the hostgenerates a complete split-transaction and a request for input data.Said complete split-transaction and request for input data aretransmitted to the LEX subsystem as a CSPLIT packet and an IN packet(CSPLIT/IN packets). On receipt of the CSPLIT/IN packets, the controllogic (351) within the LEX subsystem recognizes the lack of data thatcorresponds to the request in its memory so said control logic (351)generates a NYET packet and transmits the same to the host. Said NYETpacket warns the host that the LEX subsystem has not yet received aresponse from the device and enables said host to progress to the nexttransaction. Said control logic (351) forwards said CSPLIT/IN packets tothe REX-FPGA subsystem. The control logic (352) within the REX-FPGAsubsystem forwards said CSPLIT/IN packets to the REX-Hub.

[0379] At a later time, the control logic (350) within the hostrecognizes that it has not received a data packet from the device andautomatically retries the transaction by issuing a further CSPLIT packetand a further IN packet to the LEX subsystem. On receipt of the furtherCSPLIT/IN packets, the control logic (351) within the LEX subsystemrecognizes that it has a data packet stored in memory from the samefunction identified by the further CSPLIT/IN packets. Said control logicretrieves said stored Result packet from memory and transmits the samepacket to the Host. Said control logic also recognizes that saidCSPLIT/IN packets are a repetition of the previous CSPLIT/IN packets andabsorbs said packets.

[0380] According to the invention, the protocol handling for controloutput transfers between a high-speed host and a full-speed device isthe same as the protocol handling for control output transfers between ahigh-speed host and a low-speed device, as described in FIG. 28 bycontrol logics (340) to (354).

[0381]FIG. 29 is a sequence diagram showing a control input transfer,between a high-speed host and a high-speed device. In the Set-up Phase,the control logic (360) within the Host generates a notification ofdevice set-up and a data packet, addressed to a particular USB function.Said notification and data are transmitted to the LEX subsystem as aSETUP packet and a DATA0 packet (SETUP/DATA0 packets). On receipt ofsaid packets, the control logic (361) within the LEX subsystemrecognizes that it has not yet received an acknowledgment from thedevice so said control logic generates a synthetic acknowledgementpacket and transmits the same as an ACK packet to the host Said controllogic (361) forwards the SETUP/DATA0 packets to the REX-FPGA subsystem.The control logic (362) within the REX-FPGA subsystem forwards saidSETUP/DATA0 packets to the REX-Hub. The control logic (363) within theREX-Hub forwards said SETUP/DATA0 packets to the Device.

[0382] On receipt of said SETUP/DATA0 packets, the control logic (364)within the device assembles the required acknowledgement packet andtransmits the same as a Result packet to the Host The control logic(363) within the REX-Hub receives said Result packet and forwards thesame packet to the REX-FPGA subsystem. The control logic (362) withinthe REX-FPGA subsystem forwards said Result packet to the LEX subsystem.The control logic (361) within the LEX subsystem recognizes that it hasalready sent an acknowledgement to the host and absorbs said Resultpacket.

[0383] In the Data Phase, the control logic (365) within the hostgenerates a request for input data addressed to the same USB function,after receiving the first Result packet. Said request for input data aretransmitted to the LEX subsystem as an IN packet. On receipt of said INpacket, the control logic (366) within the LEX subsystem recognizes thelack of data that corresponds to the input request in its buffer memoryso said control logic generates a synthetic negative acknowledgementpacket and transmits the same as a NAK packet to the host. Said controllogic (366) forwards the IN packet to the REX-FPGA subsystem. Thecontrol logic (367) within the REX-FPGA subsystem forwards said INpacket to the REX-Hub. The control logic (368) within the REX-Hubforwards the request for input data to the Device as an IN packet.

[0384] On receipt of the IN packet, the control logic (369) within thedevice assembles the requested control data and transmits the same tothe REX-Hub as a Result packet. The control logic (368) within theREX-Hub forwards said Result packet to the REX-FPGA subsystem. Onreceipt of said Result packet, the control logic (367) within theREX-FPGA subsystem generates a synthetic acknowledgement packet. Saidacknowledgement packet is transmitted to the REX-Hub as an ACK packet.The control logic (368) within the REX-Hub forwards said ACK packet tothe device. The control logic (367) within the REX-FPGA subsystemforwards said Result packet to the LEX subsystem and the control logic(366) within the LEX subsystem stores said Result packet in its buffermemory.

[0385] At a later time, the control logic (365) within the hostrecognizes that it has not received the requested input data andautomatically retries the transaction by issuing a further requestaddressed to the same USB function. Said request is transmitted to theLEX subsystem as an IN packet On receipt of the IN packet, the controllogic (366) within the LEX subsystem recognizes that it has a Resultpacket stored in memory from the same function identified by the furtherIN packet. Said control logic retrieves said stored Result packet frommemory and transmits the same packet to the Host Said control logic(366) also recognizes that said IN packet is a repetition of theprevious IN packet and absorbs said packet Upon successful receipt ofthe Result packet, the control logic (365) within the host generates anACK packet to acknowledge a successful transmission. When the controllogic (366) within the LEX subsystem receives the ACK packet from thehost, said control logic absorbs said packet.

[0386] The above-described process is repeated for subsequent input datarequests from the Host by the distributed control logic (e.g. 365, 366,367, 368, 369). The control logic within the host will continue togenerate requests for input data until the last data packet is received.

[0387] In the Status Phase, the control logic (370) within the hostgenerates a notification of output data and a data packet, addressed tothe same USB function. Said notification and data are transmitted to theLEX subsystem as OUT/DATA1 packets. On receipt of said OUT/DATA1packets, the control logic (371) within the LEX subsystem recognizes ithas not received an acknowledgement from the device so said controllogic generates a synthetic negative acknowledgement packet andtransmits the same as a NAK packet to the host. Said control logic (371)forwards the OUT/DATA1 packets to the REX-FPGA subsystem. The controllogic (372) within the REX-FPGA subsystem forwards said OUT/DATA1packets to the REX-Hub. The control logic (373) within the REX-Hubforwards said OUT/DATA1 packets to the Device.

[0388] On receipt of the OUT/DATA1 packets, the control logic (374)within the device assembles the required acknowledgement packet andtransmits the same as a Result packet to the REX-Hub. The control logic(373) within the REX-Hub receives said Result packet and forwards thesame packet to the REX-FPGA subsystem. The control logic (372) withinthe REX-FPGA subsystem forwards said Result packet to the LEX subsystem.The control logic (371) within the LEX subsystem stores said Resultpacket in its buffer memory.

[0389] At a later time, the control logic (370) within the hostrecognizes that it has not received the requested Result andautomatically retries the transaction by generating further OUT/DATA1packets addressed to the same USB function and transmitting the same tothe LEX subsystem. On receipt of the OUT/DATA1 packets, the controllogic (371) within the LEX subsystem recognizes that it has a Resultpacket stored in memory from the same function identified by the furtherOUT/DATA1 packets. Said control logic retrieves said stored Resultpacket from memory and transmits the same packet to the Host. Saidcontrol logic (371) also recognizes that said OUT/DATA1 packets are arepetition of the previous OUT/DATA1 packets and absorbs said packets.

[0390] The sequence for the Data Phase described above by thedistributed control logics 365-369 also serves to describe the operationof a bulk input transfer between a high-speed host and a high-speeddevice.

[0391]FIG. 30 is a sequence diagram showing a control output transfer,between a high-speed host and a high-speed device. In the Set-up Phase,the control logic (360) within the Host generates a notification ofdevice set-up and a data packet addressed to a particular USB function.Said notification and data packet are transmitted to the LEX subsystemas a SETUP packet and a DATA0 packet (SETUP/DATA0 packets). On receiptof the SETUP/DATA0 packets, the control logic (361) within the LEXsubsystem recognizes that it has not received an acknowledgement fromthe device so said control logic generates a synthetic acknowledgementpacket and transmits the same as an ACK packet to the host. Said controllogic (361) forwards the SETUP/DATA0 packets to the REX-FPGA subsystem.The control logic (362) within the REX-FPGA subsystem forwards saidSETUP/DATA0 packets to the REX-Hub. The control logic (363) within theREX-Hub forwards said SETUP/DATA0 packets to the device.

[0392] On receipt of the SETUP/DATA0 packets, the control logic (364)within the device assembles the requested Result and transmits the sameas a Result packet to the REX-Hub. The control logic (363) within theREX-Hub forwards said Result packet to the REX-FPGA subsystem. Thecontrol logic (362) within the REX-FPGA subsystem forwards said Resultpacket to the LEX subsystem. The control logic (361) within the LEXsubsystem recognizes that it has already sent an acknowledgement to thehost and absorbs said Result packet.

[0393] In the Data Phase, the control logic (365) within the hostgenerates a notification of output data and a data packet, addressed tothe same USB function as in the Set-up Phase. Said notification and datapacket are transmitted as OUT/DATA1 packets to the LEX subsystem. Onreceipt of the OUT/DATA1 packets, the control logic (366) within the LEXsubsystem recognizes that it has not received an acknowledgement packetfrom the device so said control logic generates a synthetic negativeacknowledgement and transmits the same as a NAK packet to the host. Saidcontrol logic (366) forwards the OUT/DATA1 packets to the REX-FPGAsubsystem. The control logic (367) within the REX-FPGA subsystemforwards said OUT/DATA1 packets to the REX-Hub. The control logic (368)within the REX-Hub forwards said OUT/DATA1 packets to the device.

[0394] On receipt of the OUT/DATA1 packets, the control logic (369)within the device assembles the requested Result and transmits the sameto the REX-Hub as a Result packet. The control logic (368) within theREX-Hub forwards said Result packet to the REX-FPGA subsystem. Thecontrol logic (367) within the REX-FPGA subsystem forwards said Resultpacket to the LEX subsystem and the control logic (366) within the LEXsubsystem stores said Result packet in its buffer memory.

[0395] At a later time, the control logic (365) within the hostrecognizes that it has not received an acknowledgement from the deviceand automatically retries the transaction by issuing a further OUTpacket and a further DATA1 packet, addressed to the same USB function.Said notification and data are transmitted as OUT/DATA1 packets to theLEX subsystem. On receipt of the OUT/DATA1 packets, the control logic(366) within the LEX subsystem recognizes that it has in its buffermemory an acknowledgement packet that corresponds to the same functionas the further OUT/DATA1 packets. Said control logic (366) retrievessaid stored Result packet from its memory and transmits the same packetto the host. Said control logic also recognizes that said OUT/DATA1packets are a repetition of the previous OUT/DATA1 packets and absorbssaid packets.

[0396] The above-described process is repeated for subsequent outputdata notifications from the Host by the distributed control logic (e.g.365, 366, 367, 368, 369). The control logic within the host willcontinue to generate notifications of output data until the last datapacket is delivered.

[0397] In the Status Phase, the control logic (370) generates a requestfor input data and transmits the same as an IN packet to the LEXsubsystem. On receipt of the IN packet, the control logic (371) withinthe LEX subsystem recognizes the lack of data that corresponds to therequest in its buffer memory so it generates a synthetic negativeacknowledgement and transmits the same as a NAK packet to the host. Saidcontrol logic (371) forwards said IN packet to the REX-FPGA subsystem.The control logic (372) within the REX-FPGA subsystem forwards said INpacket to he REX-Hub. The control logic (373) within the REX-Hubforwards said IN packet to the device.

[0398] On receipt of the IN packet, the control logic (374) within thedevice assembles the requested data and transmits the same as a Resultpacket to the REX-Hub. The control logic (373) within the REX-Hubforwards said Result packet to the REX-FPGA subsystem. On receipt of theResult packet, the control logic (372) within the REX-FPGA subsystemgenerates a synthetic acknowledgement packet and transmits the same asan ACK packet to the REX-Hub. The control logic (373) within the REX-Hubforwards said ACK packet to the device. The control logic (372) withinthe REX-FPGA subsystem forwards the Result packet to the LEX subsystemand the control logic (371) within the LEX subsystem stores said Resultpacket in its buffer memory.

[0399] At a later time, the control logic (370) within the hostrecognizes that it has not received the requested data packet andautomatically retries the transaction by issuing a further request forinput data, addressed to the same USB function. Said request for inputdata is transmitted as an IN packet to the LEX subsystem. On receipt ofthe IN packet, the control logic (371) within the LEX subsystemrecognizes that it has in its buffer memory a Result packet thatcorresponds to the same function as the further input request. Saidcontrol logic (371) retrieves said stored Result packet from its memoryand transmits the same packet to the host. Said control logic alsorecognizes that said IN packet is a repetition of the previous IN packetand absorbs said packet. Upon successful receipt of the Result packet,the control logic (370) within the host generates an ACK packet toacknowledge a successful transmission. When the control logic (371)within the LEX subsystem receives the ACK packet from the host, saidcontrol logic absorbs said packet.

[0400] The sequence for the Data Phase described above by thedistributed control logics 365-369 also serves to describe the operationof a bulk output transfer between a high-speed host and a high-speeddevice.

[0401]FIG. 31 is a sequence diagram showing a bulk input transfer,between a high-speed host and a full-speed device. The control logic(410) within the host generates a start split-transaction and a requestfor input data addressed to a particular USB function. Said startsplit-transaction and request for input data are transmitted to the LEXsubsystem as a SSPLIT packet and an IN packet (SSPLIT/IN packets). Onreceipt of the SSPLIT/IN packets, the control logic (411) within the LEXsubsystem recognizes that it has not yet received an acknowledgementfrom the device so said control logic generates a synthetic negativeacknowledgement and transmits the same to the host as a NAK packet Saidcontrol logic (411) forwards said SSPLIT/IN packets to the REX-FPGAsubsystem. The control logic (412) within the REX-FPGA subsystemforwards said SSPLIT/IN packets to the REX-Hub.

[0402] On receipt of the SSPLIT/IN packets, the control logic (413)within the REX-Hub generates an acknowledgement packet and transmits thesame to the REX-FPGA subsystem as a Result packet. The control logic(412) within the REX-FPGA subsystem forwards said Result packet to theLEX subsystem and the control logic (411) within the LEX subsystemstores said Result packet in its buffer memory. The control logic (413)within the REX-Hub absorbs said SSPLIT packet and forwards said INpacket to the device. On receipt of said IN packet, the control logic(414) within the device assembles the requested data and transmits thesame as a Result packet to the REX-Hub. The control logic (413) withinthe REX-Hub stores said Result packet in its buffer memory. On receiptof the Result packet, said control logic (413) generates an ACK packetto acknowledge a successful transmission.

[0403] At a later time, the control logic (410) within the hostrecognizes that it has not received the requested data from the deviceand automatically retries the transaction by issuing a further startsplit-transaction and a request for input data addressed to the same USBfunction. Said start split-transaction and request for input data aretransmitted as SSPLIT/IN packets to the LEX subsystem. On receipt of theSSPLIT/IN packets, the control logic (411) within the LEX subsystemrecognizes that it has an acknowledgement packet stored in memory fromthe same function identified by the further SSPLIT/IN packets. Saidcontrol logic retrieves the stored acknowledgement packet from memoryand transmits the same as a Result packet to the Host. Said controllogic (411) also recognizes that said SSPLIT/IN packets are merely arepetition of the previous SSPLIT/IN packets and absorbs said packets.

[0404] At a later time, the control logic (410) within the hostgenerates a complete split-transaction and a request for input data,addressed to the same USB function. Said complete split-transaction andrequest for input data are transmitted as CSPLIT/IN packets to the LEXsubsystem. On receipt of the CSPLIT/IN packets, the control logic (411)within the LEX subsystem recognizes that it has not received anacknowledgment packet from the device so said control logic generates asynthetic NYET packet and transmits the same to the host. Said NYETpacket informs the host that the LEX subsystem has not yet received aresponse from the device and enables said host to progress to the nexttransaction. The control logic (411) within the LEX subsystem forwardssaid CSPLIT/IN packets to the REX-FPGA subsystem. The control logic(412) within the REX-FPGA subsystem forwards said CSPLIT/IN packets tothe REX-Hub.

[0405] On receipt of the CSPLIT/IN packets, the control logic (413)within the REX-Hub recognizes that it has in its buffer memory a Resultpacket that corresponds to the input data request. Said control logic(413) retrieves said stored Result packet and transmits the same to theREX-FPGA subsystem. The control logic (412) within the REX-FPGAsubsystem forwards said Result packet to the LEX subsystem and thecontrol logic (411) within the LEX subsystem stores said Result packetin its buffer memory.

[0406] At a later time, the control logic (410) within the hostrecognizes that it has not received the requested data from the deviceand automatically retries the transaction by issuing a further completesplit-transaction and a request for input data, addressed to the sameUSB function. Said complete split-transaction and request for input dataare transmitted to the LEX subsystem as further CSPLIT/IN packets. Onreceipt of the further CSPLIT/IN packets, the control logic (411) withinthe LEX subsystem recognizes that it has a Result packet stored inmemory from the same function identified by the further CSPLIT/INpackets. Said control logic retrieves said stored Result packet frommemory and transmits the same packet to the Host. Said control logic(411) also recognizes that said CSPLIT/IN packets are merely arepetition of the previous CSPLIT/IN packets and absorbs said packets.

[0407] The above-described process is repeated for subsequent input datarequests from the Host by the distributed control logic (e.g. 410, 411,412, 413, 414).

[0408]FIG. 32 is a sequence diagram showing a bulk output transfer,between a high-speed host and a full-speed device. The control logic(410) within the host generates a start split-transaction, anotification of output data, and a data packet, addressed to aparticular USB function. Said start split-transaction, notification ofoutput data, and data packet are transmitted to the LEX subsystem as aSSPLIT packet, an OUT packet and a DATAX packet, respectively. SaidDATAX packet represents a DATA0 packet or a DATA1 packet. On receipt ofthe SSPLIT/OUT/DATAX packets, the control logic (411) within the LEXsubsystem recognizes the lack of Result that corresponds to the inputrequest in its buffer memory so said control logic generates a syntheticnegative acknowledgement and transmits the same to the host as a NAKpacket. Said control logic (411) forwards said SSPLIT/OUT/DATAX packetsto the REX-FPGA subsystem. The control logic (412) within the REX-FPGAsubsystem forwards said SSPLIT/OUT/DATA1 packets to the REX-Hub.

[0409] On receipt of the SSPLIT/OUT/DATAX packets, the control logic(413) within the REX-Hub generates an acknowledgement packet andtransmits the same to the REX-FPGA subsystem as a Result packet. Thecontrol logic (412) within the REX-FPGA subsystem forwards said Resultpacket to the LEX subsystem and the control logic (411) within the LEXsubsystem stores said Result packet in its buffer memory. The controllogic (413) within the REX-Hub absorbs said SSPLIT packet and forwardssaid OUT/DATAX packets to the device. On receipt of said OUT/DATAXpackets, the control logic (414) within the device assembles therequested Result and transmits the same as a Result packet to theREX-Hub.

[0410] The control logic (413) within the REX-Hub stores said Resultpacket in its buffer memory. At a later time, the control logic (410)within the host recognizes that it has not received the requested Resultand automatically retries the transaction by issuing furtherSSPLIT/OUT/DATAX packets addressed to the same USB function andtransmitting the same to the LEX subsystem. On receipt of theSSPLIT/OUT/DATAX packets, the control logic (411) within the LEXsubsystem recognizes that it has a Result packet stored in memory fromthe same function identified by the further SSPLIT/OUT/DATAX packets.Said control logic retrieves said stored Result packet from memory andtransmits the same packet to the Host. Said control logic (411) alsorecognizes that said SSPLIT/OUT/DATAX packets are a repetition of theprevious SSPLIT/OUT/DATAX packets and absorbs said packets.

[0411] At a later time, the control logic (410) within the hostgenerates a complete split-transaction and a notification of outputdata. Said complete split-transaction and notification of output dataare transmitted to the LEX subsystem as a CSPLIT packet and an OUTpacket. On receipt of the CSPLIT/OUT packets, the control logic (411)within the LEX subsystem recognizes the lack of Result that correspondsto the notification of output data in its memory so said control logic(411) generates a NYET packet and transmits the same to the host SaidNYET packet warns the host that the LEX subsystem has not yet received aresponse from the device and enables said host to progress to the nexttransaction. Said control logic (411) forwards said CSPLIT/SETUP packetsto the REX-FPGA subsystem. The control logic (412) within the REX-FPGAsubsystem forwards said CSPLIT/OUT packets to the REX-Hub.

[0412] On receipt of the CSPLIT/OUT packets, the control logic (413)within the REX-Hub recognizes that it has a Result packet stored inmemory from the same function identified by the further CSPLIT/OUTpackets. Said control logic retrieves said stored Result packet frommemory and transmits the same packet to the REX-FPGA subsystem. Thecontrol logic (412) within the REX-FPGA subsystem forwards said Resultpacket to the LEX subsystem and the control logic (411) within the LEXsubsystem stores said Result packet in its buffer memory.

[0413] At a later time, the control logic (410) within the hostrecognizes that it has not received the requested Result andautomatically retries the transaction by issuing a further CSPLIT packetand a further OUT packet to the LEX subsystem. On receipt of theCSPLIT/OUT packets, the control logic (411) within the LEX subsystemrecognizes that it has a Result packet stored in memory from the samefunction identified by the further CSPLIT/OUT packets. Said controllogic retrieves said stored Result packet from memory and transmits thesame packet to the Host. Said control logic (411) also recognizes thatsaid CSPLIT/OUT packets are a repetition of the previous CSPLIT/OUTpackets and absorbs said packets.

[0414]FIG. 33 provides a sequence diagram showing a PING protocolaccording to the invention.

[0415] The control logic (500) within the host generates a high-speedflow control probe for a bulk/control endpoint, addressed to aparticular USB function, and transmits the same to the LEX subsystem asa PING packet. On receipt of said PING packet, the control logic (501)within the LEX subsystem recognizes that it has not yet received anacknowledgment from the device corresponding to said PING packet. Saidcontrol logic generates a synthetic negative acknowledgment packet andtransmits the same as a NAK packet to the host. Said control logic (501)forwards said PING packet to the REX-FPGA subsystem. The control logic(502) within the REX-FPGA subsystem forwards said PING packet to theREX-Hub. The control logic (503) within the REX-Hub forwards said PINGpacket to the Device.

[0416] Upon successful receipt of said PING packet, the control logic(504) within the device generates an acknowledgment and transmits thesame to the REX-Hub as a Result packet. The control logic (503) withinthe REX-Hub forwards said Result packet to the REX-FPGA subsystem. Thecontrol logic (502) within the REX-FPGA subsystem forwards said Resultpacket to the LEX subsystem and the control logic (501) within the LEXsubsystem stores said Result packet in its buffer memory.

[0417] At a later time, the control logic (500) within the host realizesthat it has not received an acknowledgment from the device andautomatically retries the transaction by issuing a further high-speedflow control probe to the same USB function. Said flow control probe istransmitted to the LEX subsystem as a PING packet On receipt of saidPING packet, the control logic (501) within the LEX subsystem recognizesthat it has an acknowledgment packet stored in its memory from the samefunction identified by the further PING packet. Said control logicretrieves said acknowledgment packet from its buffer memory andtransmits the same to the host as a Result packet Said control logic(501) also recognizes said further PING packet is merely a repetition ofthe previous PING packet and absorbs said packet.

[0418] The above-described process is repeated for subsequent high-speedflow control probes from the Host by the distributed control logic (e.g.500, 501, 502, 503, 504).

[0419] Thus, it is apparent that there have been provided, in accordancewith the present invention, USB devices which fully, or at leastpartially, satisfy the means, objects, and advantages over the prior artas set forth hereinbefore. Therefore, having described specificembodiments of the present invention, it will be understood thatalternatives, modifications and variations thereof may be suggested tothose skilled in the art, and that it is intended that the presentspecification embrace all such alternatives, modifications andvariations as fall within the scope of the appended claims.

[0420] Additionally, for clarity and unless otherwise stated, the word“comprise” and variations of the word such as “comprising” and“comprises”, when used in the description and claims of the presentspecification, is not intended to exclude other additives, components,integers or step.

We claim:
 1. An enhanced high-speed method for transmitting a datastream between a host controller and a peripheral device over anextended distance, on a signal distribution system, in accordance withthe USB-Extended Range Protocol (USB-ERP) wherein said methodadditionally comprises modifications to allow for compliance withRevision 2.0 of the USB specification.
 2. An enhanced high-speed methodof transmitting a data stream as claimed in claim 1 wherein saidenhanced high-speed USB-ERP comprises: a. feeding a first original,outgoing digital signal from a host controller to a local expander unit;b. optionally converting said outgoing digital signals into a convertedoutgoing signal having a format suitable for transmission over extendeddistances; c. transmitting either said outgoing digital signal or saidconverted outgoing signal, as a outgoing transmission signal, over asignal distribution system; d. receiving said outgoing transmissionsignal at a remote expander unit; e. optionally converting said outgoingtransmission signal to said first original outgoing digital signal; f.delivering said first original outgoing digital signal from said remoteexpander to at least one peripheral device; g. receiving, at said remoteexpander, a reply digital signal from said peripheral device; h.optionally converting said reply digital signal into a converted replysignal having a format suitable for transmission over extendeddistances; i. transmitting said reply digital signal or said convertedreply signal as a reply transmission signal over said signaldistribution system; j. receiving said reply transmission signal at saidlocal expander; k. optionally converting said reply transmission signalto said original reply digital signal; l. storing said reply digitalsignal as a stored reply digital signal until the receipt of asubsequent original, outgoing digital signal from said host controller,which subsequent signal is the same as, or similar to, said firstoriginal outgoing digital signal; and m. forwarding said stored replydigital signal to said host controller in response to said subsequentoriginal outgoing digital signal.
 3. A method as claimed in claim 2wherein said data stream is a time relevant data stream.
 4. A method asin claim 2 wherein said digital signals conform to the USB Specificationand represent isochronous data.
 5. A method as claimed in claim 4wherein said method provides a method for transmission of isochronousdata according to the USB Specification wherein isochronous data istransmitted from a peripheral device and is received by a hostcontroller, said method comprising: a. transmitting a request forisochronous data from a host controller to a local expander, b.forwarding said request for isochronous data from said local expander toa remote expander over a signal distribution system; c. delivering saidforwarded request for isochronous data to at least one peripheraldevice; d. transmitting the requested isochronous data from saidperipheral device to said remote expander; e. forwarding said requestedisochronous data from said remote expander to said local expander oversaid signal distribution system; f. storing said requested isochronousdata in a packet buffer at said local expander, g. transmitting asubsequent request for isochronous data from said host controller tosaid local expander; h. receiving said subsequent request forisochronous data at said local expander; and I. retrieving the storedisochronous data from said local expander; II. delivering said storedisochronous data to said host controller; III. forwarding saidsubsequent request for isochronous data from said local expander to saidremote expander over said signal distribution system; and IV. repeatingsteps (c) through (h) for said subsequent request and any furthersubsequent requests for isochronous data.
 6. A method as claimed inclaim 4 wherein said method provides a method for transmission ofisochronous data according to the USB Specification wherein isochronousdata is transmitted from a host controller and is received by aperipheral device, said method comprising: a) receiving, at a localexpander, an original notification of isochronous data from a hostcontroller; b) forwarding said original notification of isochronous datafrom said local expander to a remote expander over a signal distributionsystem; c) receiving, at a remote expander, said forwarded originalnotification of isochronous data; d) delivering said forwardednotification of isochronous data to at least one peripheral device; e)receiving, at a local expander, an original isochronous data packet froma host controller; f) forwarding said original isochronous data packetfrom said local expander to a remote expander over a signal distributionsystem; g) receiving, at a remote expander, said forwarded originalisochronous data packet; and h) delivering said forwarded originalisochronous data packet to at least one peripheral device.
 7. A methodas claimed in claim 5 additionally comprising the following steps afterstep (b) of claim 5 namely: i. Determining whether said local expanderalready possesses said requested isochronous data; ii. Generating asynthetic data packet if no such requested isochronous data is present;and iii. Delivering said synthetic isochronous data to said hostcontroller.
 8. A method as claimed in claim 5 additionally comprisingthe following steps after step (b) of claim 5, uniquely for datatransfers conforming to the USB Specification wherein data istransmitted from a high-speed host and is received by a full-speeddevice, namely: i) Determining whether said local expander alreadypossesses said requested isochronous data; ii) Generating a syntheticnot-yet packet if no such requested isochronous data is present; andiii) Delivering said not-yet packet to said host controller.
 9. A methodas claimed in claim 5 additionally comprising the following step afterstep (c) of claim 5, namely: i) Storing the address of the requestedperipheral device at said remote expander unit; a) Retrieving theaddress of said requested peripheral device at said remote expanderunit; and b) Adding said retrieved address to said requested isochronousdata.
 10. A method as claimed in claim 5 wherein vestigial packets areremoved from system, said method comprising: i) Detecting when a newframe has begun; ii) Examining the properties of each packet buffer;iii) Determining whether the data packet contained in said examinedpacket buffer has been stored for at least one complete frame period;iv) Discarding said contained data packet if said contained data packethas been stored for at least one complete frame period; and v) Repeatingsteps (i) through (iv) for each packet buffer in the system.
 11. Anenhanced high-speed method as claimed in claim 2 wherein said datastream is non-time-relevant data stream.
 12. A method as in claim 2wherein said digital signals conform to USB Specification and representasynchronous data.
 13. A method as claimed in claim 12 wherein saidmethod provides a method for transmission of asynchronous data accordingto the USB Specification wherein asynchronous data is transmitted from aperipheral device and is received by a host controller, said methodcomprising: a) receiving, at a local expander, an original request forasynchronous data from a host controller; b) forwarding said originalrequest for asynchronous data from said local expander to a remoteexpander over a signal distribution system; c) receiving, at a remoteexpander, said forwarded original request for asynchronous data; d)delivering said forwarded original request for asynchronous data fromsaid peripheral device; e) receiving, at said remote expander, therequested asynchronous data to at least one peripheral device; f)forwarding said requested asynchronous data from said remote expander tosaid local expander over said signal distribution system; g) storing, ina packet buffer at said local expander, said requested asynchronousdata; h) receiving, at said local expander, a subsequent request forasynchronous data from said host controller; and i) retrieving thestored asynchronous data from said packet buffer; ii) delivering saidretrieved asynchronous data to said host controller; i) receiving, atsaid local expander, an outgoing acknowledgment signal from said hostcontroller; j) absorbing, at said local expander, said outgoingacknowledgement signal.
 14. A method as claimed in claim 13 additionallycomprising the following steps after step (b) of claim 13, namely: i)Determining whether said local expander already possesses said requestedasynchronous data; ii) Generating a negative acknowledgement packet ifno such requested asynchronous data is present; and iii) Delivering saidnegative acknowledgement packet to said host controller.
 15. A method asclaimed in claim 13 additionally comprising the following steps afterstep (b) of claim 13, generally for high bandwidth data transfersconforming to the USB Specifications wherein data is transmitted from ahigh-speed host and is received by a high-speed device, namely: a.Determining whether said local expander already possesses said requestedasynchronous data; b. Generating a synthetic data packet if no suchrequested asynchronous data is present; and c. Delivering said syntheticdata packet to said host controller.
 16. A method as claimed in claim 13additionally comprising following steps after step (b) of claim 13,uniquely for data transfers conforming to the USB Specifications whereindata is transmitted from a high-speed host and is received by alow-speed or full-speed device, namely: a. Determining whether saidlocal expander already possesses said requested asynchronous data; b.Generating a synthetic not-yet packet if no such requested asynchronousdata is present; and c. Delivering said synthetic not-yet packet to saidhost controller.
 17. A method as claimed in claim 13 additionallycomprising the following steps after step (e) of claim 13, namely: i)generating an acknowledgement packet at said remote expander; and ii)delivering said acknowledgement packet to said peripheral device.
 18. Amethod as claimed in claim 13 additionally comprising the followingsteps after step (h) of claim 13, uniquely for interrupt data transfersconforming to the USB Specifications wherein asynchronous data istransmitted from a peripheral device and is received by a hostcontroller, namely: a. Forwarding said subsequent request forasynchronous data from said local expander to a remote expander over asignal distribution system; b. Delivering said forwarded subsequentrequest for asynchronous data to said peripheral device; and c.Receiving, at said remote expander, the requested asynchronous data fromsaid peripheral device.
 19. A method as claimed in claim 13 additionallycomprising the following step after step (h) of claim 13, uniquely forcontrol and bulk data transfers conforming to the USB Specificationswherein asynchronous data Is transmitted from a peripheral device and isreceived by a host controller, namely: a. Absorbing at said localexpander said subsequent request for asynchronous data.
 20. A method asclaimed in claim 13 wherein, additionally, a guard time is imposed aftera data packet is transmitted from a remote expander to a USB device,which guard time is set to a value that is dependent upon the transfertype of said transmitted data packet, said method comprising: a)Receiving, at a remote expander, an outbound data packet, b)Determining, at a remote expander, the transfer type of said outbounddata packet, c) Forwarding said outbound data from said remote expanderto a USB device, d) Setting the value of a transmission guard timer to avalue that is dependent upon said determined transfer type; and e)Inhibiting further outbound transmissions until said guard timer hasexpired.
 21. A method as claimed in claim 12 wherein said methodprovides a method for transmission of asynchronous data according to theUSB Specification wherein asynchronous data is transmitted from a hostcontroller and is received by a peripheral device, said methodcomprising: a) receiving, at a local expander, an original notificationof asynchronous data from a host controller; b) forwarding said originalnotification of asynchronous data from said local expander to a remoteexpander over a signal distribution system; c) receiving, at a remoteexpander, said forwarded original notification of asynchronous data; d)delivering said forwarded notification of asynchronous data to at leastone peripheral device; e) receiving, at a local expander, an originalasynchronous data packet from a host controller; f) forwarding saidoriginal asynchronous data packet from said local expander to a remoteexpander over a signal distribution system; g) receiving, at a remoteexpander, said forwarded original asynchronous data packet; h)delivering said forwarded original asynchronous data packet to at leastone peripheral device; i) receiving, at said remote expander, an inboundacknowledgement packet from said peripheral device; j) forwarding saidinbound acknowledgment packet from said remote expander to said localexpander over said signal distribution system; k) storing, In a packetbuffer at said local expander, said inbound acknowledgement packet; l)receiving, at said local expander, a subsequent notification ofasynchronous data from said host controller; m) receiving, at said localexpander, a subsequent asynchronous data packet from said hostcontroller; and i) retrieving said stored inbound acknowledgement packetfrom said packet buffer; and ii) delivering said retrieved inboundacknowledgement packet to said host controller.
 22. A method as claimedin claim 21 additionally comprising the following steps after step (e)of claim 21, namely: i) Determining whether said local expander alreadypossesses said inbound acknowledgement packet; ii) Generating a negativeacknowledgment packet if no such inbound acknowledgement packet ispresent; and iii) Delivering said negative acknowledgement packet tosaid host controller.
 23. A method as claimed in claim 21 additionallycomprising the following steps after step (e) of claim 21, generally forinterrupt data transfers conforming to the USB Specifications whereinasynchronous data is transmitted from a high-speed host and is receivedby a high-speed device, namely: a. Generating a syntheticacknowledgement packet at said local expander; and b. Delivering saidacknowledgment packet to said host controller
 24. A method as claimed inclaim 21 additionally comprising the following steps after step (e) ofclaim 21, uniquely for interrupt data transfers conforming to the USBSpecifications wherein asynchronous data is transmitted from ahigh-speed host and is received by a low-speed or full-speed device,namely: i) Determining whether said local expander already possessessaid inbound acknowledgment packet; ii) Generating a not-yet packet ifno such inbound acknowledgement packet is present; and iii) Deliveringsaid not-yet packet to said host controller.
 25. A method as claimed inclaim 21 additionally comprising the following steps after steps (l) and(m) of claim 21, uniquely for interrupt data transfers conforming to theUSB Specifications wherein asynchronous data is transmitted from a hostcontroller and is received by a peripheral device, namely: i. Forwardingsaid subsequent notification of asynchronous data and asynchronous datapacket from said local expander to a remote expander a signaldistribution system; ii. Delivering said forwarded subsequentnotification of asynchronous data and asynchronous data packet to saidperipheral device; iii. Receiving, at said remote expander, the inboundacknowledgement packet from said peripheral device; iv. Repeating steps(l) through (m) for said subsequent notification and data packet and anyfurther subsequent notifications of asynchronous data and asynchronousdata packets.
 26. A method as claimed in claim 21 additionallycomprising the following step after steps (l) and (m) of claim 21,uniquely for control and bulk data transfers conforming to the USBSpecifications wherein asynchronous data is transmitted from a hostcontroller and is received by a peripheral device, namely: i. Absorbingat said local expander said subsequent notification of asynchronous dataand said subsequent asynchronous data packet
 27. A method as claimed inclaim 21 wherein said method provides a method for handling the PINGflow control protocol, uniquely for control and bulk data transferswherein asynchronous data is transmitted from a high-speed host to ahigh-speed device, said method comprising: a) receiving, at a localexpander, a PING flow control probe from a host controller; b)forwarding said flow control probe from said local expander to a remoteexpander over a signal distribution system; c) receiving, at a remoteexpander, said forwarded flow control probe; d) delivering saidforwarded flow control probe to at least one high-speed peripheraldevice; e) receiving, at said remote expander, the requested reply fromsaid peripheral device; f) receiving, at said local expander, saidrequested reply; g) storing, in a packet buffer at said local expander,said requested reply; h) receiving, at said local expander, a subsequentPING flow control probe from said host controller, and i. retrievingsaid stored, requested reply from said packet buffer; ii. deliveringsaid retrieved reply to host controller. i) absorbing, at said localexpander, said subsequent flow control probe.
 28. A method as claimed inclaim 27 additionally comprising the following step after step (b) ofclaim 27, namely: i) Determining whether said local expander alreadypossesses said requested reply; ii) Generating a negativeacknowledgement packet if no such requested reply is present; iii)Delivering said negative acknowledgement packet to said host controller.29. A method as claimed in claim 21 wherein, additionally, a guard timeis imposed after a data packet is transmitted from a remote expander toa USB device, which guard time is set to a value that is dependent uponthe transfer type of said transmitted data packet, said methodcomprising: (a) Receiving, at a remote expander, an outbound datapacket, (b) Determining, at a remote expander, the transfer type of saidoutbound data packet, (c) Forwarding said outbound data packet from saidremote expander to a USB device, (d) Setting the value of a transmissionguard timer to a value that is dependent upon said determined transfertype; and (e) Inhibiting further outbound transmissions until said guardtimer has expired.
 30. An enhanced high-speed method as claimed in claim1 wherein said host controller is a PC, and said peripheral device is acamera, a mouse, a keyboard, a monitor or a speaker or speakers.
 31. Anenhanced high-speed method as in claim 1 wherein said extended distanceexceeds 5 meters.
 32. A method as claimed in claim 1 wherein saidextended distance exceeds 30 meters.
 33. A method as claimed in claim 1wherein said extended distance is equal to or exceeds 100 meters.
 34. Anenhanced high-speed method as in claim 1 wherein said signaldistribution system utilizes fibre optic cabling.
 35. An enhancedhigh-speed method as in claim 1 wherein said signal distribution systemutilizes unshielded twisted pair (UTP) wiring.
 36. An enhancedhigh-speed method as in claim 1 wherein said signal distribution systemutilizes wireless transmission.
 37. An apparatus for transmission of adigital signal over an extended distance, on a signal distributionsystem, between a host controller and a peripheral device, in accordancewith an enhanced high-speed USB-Extended Range Protocol (USB-ERP)wherein said apparatus comprises an enhanced high speed USB_ERP devicecomprising means for modification of the transmission signal to allowfor compliance with Revision 2.0 of the USB specification.
 38. Anapparatus as claimed in claim 37 wherein said enhanced high-speedUSB-ERP device comprises: a local expander comprising means forreceiving a request for a data signal from a host controller which hostcontroller is connected to said local expander, means in said localexpander for generating an outgoing transmission signal; means in saidlocal expander for sending said outgoing transmission signal to a remoteexpander, which signal is sent over a signal distribution system; aremote expander comprising means for receiving said outgoingtransmission signal; means in said remote expander for generating adigital signal from said outgoing transmission signal; means in saidremote expander for forwarding said digital signal to at least oneperipheral device, which peripheral device is connected to said remoteexpander; means in said remote expander for receiving inbound digitalsignals from said peripheral devices; means in said remote expander forconverting said inbound digital signals to an inbound transmissionsignal; means in said remote expander for sending said inboundtransmission signal to said local expander, which signals are sent oversaid signal distribution system; means in said local expander forreceiving said inbound transmission signal; means in said local expanderfor generating a digital signal from said inbound transmission; andmeans in said remote expander for forwarding said digital signal to saidhost controller.
 39. An apparatus as claimed in claim 38 wherein saiddata signal is a time relevant data signal.
 40. An apparatus as claimedin claim 39 wherein said time relevant signal is a digital signal whichconforms to the USB Specification; and said time relevant signalrepresent isochronous data.
 41. An apparatus as claimed in claim 40where in said local expander additionally comprises: means for storingsaid inbound signal as a stored inbound signal; means for analyzing saiddigital signal from said host controller to recognize a subsequentrequest for transmission of said time relevant digital signal; and meansfor sending said stored inbound signal to said host controller inresponse to said subsequent request.
 42. An apparatus as claimed inclaim 38 wherein said digital signal is a non time-relevant signal whichconforms to the USB Specification; and said non time-relevant signalrepresents asynchronous data.
 43. An apparatus as claimed in claim 42for transmission of digital signal over an extended distance comprising:a) a local expander comprising means for receiving a request for a nontime-relevant data signal, wherein said non time-relevant data signal isa digital signal which conforms to the USB Specification, from a hostcontroller connected to said local expander; b) means in said localexpander for generating an outgoing transmission signal; c) means insaid local expander for sending said outgoing transmission signal to aremote expander, which signals are sent over a signal distributionsystem; d) a remote expander comprising means for receiving saidoutgoing transmission signal; e) means in said remote expander forgenerating a digital signal from said outgoing transmission signal; f)means in said remote expander for forwarding said digital to at leastone peripheral device, which peripheral device is connected to saidremote expander; g) means in said remote expander for receiving inbounddigital signals from said peripheral devices; h) means in said remoteexpander for converting said inbound digital signals to an inboundtransmission signal; i) means in said remote expander for sending saidinbound transmission signal to said local expander, which signals aresent over said signal distribution system; j) means in said localexpander for receiving said inbound transmission signal; k) means insaid local expander for generating a digital signal from said inboundtransmission; and l) means in said local expander for forwarding saiddigital signal to said host controller.
 44. An apparatus as claimed inclaim 43 wherein said local expander additionally comprises: a) meansfor storing said inbound signal as a stored inbound signal; b) means foranalyzing said digital signal from said host controller to recognize asubsequent request for transmission of said non time-relevant digitalsignal; and c) means for sending said stored inbound signal to said hostcontroller in response to said subsequent request
 45. An apparatus asclaimed in claim 37 wherein said extended distance exceeds 5 meters. 46.An apparatus as claimed in claim 37 wherein said extended distanceexceeds 30 meters.
 47. An apparatus as claimed in claim 37 wherein saidextended distance is equal to or exceeds 100 meters.
 48. An apparatus asclaimed in claim 37 wherein said signal distribution system utilizesfibre optic cabling.
 49. An apparatus as claimed in claim 37 whereinsaid signal distribution system utilizes unshielded twisted pair (UTP)wiring.
 50. An apparatus as claimed in claim 37 wherein said signaldistribution system utilizes wireless transmission.
 51. An apparatus asclaimed in claim 37 wherein said host controller is a PC, and saidperipheral device is a camera, a mouse, a keyboard, a monitor or aspeaker or speakers.